Werden Sie ein Open-Source-Programmierer in der Drupal-Community

Als eine der bekanntesten CMS-Plattformen hat Drupal eine riesige Gemeinschaft, die tagtäglich sowohl an der Entwicklung und Verbesserung des Systemkerns als auch an Projekten arbeitet, die seine Funktionalitäten erweitern. Das Motto der Gemeinschaft lautet: „Kooperation statt Konkurrenz“ – anstatt viele konkurrierende Module anzubieten, werden individuelle Lösungen zur Lösung eines bestimmten Problems geschaffen.

Das modulare System ermöglicht es sogar weniger erfahrenen Drupal-Entwicklern, bei der täglichen Programmierarbeit an verschiedenen Projekttypen zu helfen. Also, wie können Sie zum Drupal-Umfeld beitragen?

Bevor ich mein eigenes Projekt erstelle

1. Recherchieren!

Bevor Sie ein Projekt starten, sollten Sie sorgfältig prüfen, ob ein solches Projekt nicht bereits erstellt wurde. Es könnte sich herausstellen, dass beispielsweise das Modul, das Sie erstellen möchten, bereits existiert oder es ausreichen würde, einen Vorschlag zur Erweiterung seiner Funktionalität einzureichen. Es ist auch gut, einen Blick auf die Liste der vorgeschlagenen Module zu werfen und die Entwicklungsarbeiten von jemandem zu unterstützen.

2. Ihr Profil auf dem drupal.org-Webportal

Falls Sie noch kein eigenes Konto auf dem drupal.org-Portal haben, möchten wir Sie nachdrücklich ermutigen, eines zu erstellen. Dadurch können Sie neue Projekte erstellen sowie Probleme und Patches zu bestehenden Projekten melden.

3. Ein Sandkastenprojekt oder ein vollständiges Projekt?

Das drupal.org-Webportal ermöglicht es Ihnen, zwei Arten von Projekten zu erstellen. Das erste davon ist ein Sandkastenprojekt. Es ist im Wesentlichen ein Testfeld für neu entwickelte Module. In der Regel übernehmen seine Ersteller keine Verantwortung für dessen Code, bis sie an einer Version arbeiten, die mindestens die grundlegenden Anforderungen an Funktionalität und Stabilität erfüllt. In diesem Stadium wird ein Sandkastenprojekt in der Regel zu einem vollständigen Projekt befördert, in dem es möglich ist, Versionen, Releases, Benachrichtigungen usw. zu erstellen.

Projekt erstellen

Der Projekterstellungsprozess ist nicht besonders kompliziert. Am Anfang sind nur einige grundlegende Informationen erforderlich – Sie müssen nicht einmal tatsächlich vorhandenen Code haben.

Sie können Ihr eigenes Projekt über Ihr Profil hinzufügen, indem Sie auf die Registerkarte „Ihre Projekte“ gehen oder direkt über die Webseite Neues Projekt hinzufügen.

Sie wählen den Projekttyp. In unserem Fall wird es ein Modul sein.
Sie füllen das Feld mit dem Modulnamen, dem Maschinenname (Kurzname) und dem Projekttyp (Sandbox/Voll) aus.
Zusätzlich ist es gut, den Namen der Organisation anzugeben, die die Entwicklung des Projekts unterstützt (dies ist eine zusätzliche Form der Werbung für das Unternehmen) und die zusätzlichen Personen, die an der Pflege des Projekts mitarbeiten werden.

Codearbeit

1. Git

Am Anfang müssen Sie Zugriff auf die Repositories basierend auf dem Git-Versionskontrollsystem erhalten. Das Drupal.org-Webportal verwendet die GitLab-Plattform, die teilweise mit dem Webportal selbst integriert ist. Sie müssen Ihren SSH-Schlüssel beim Bearbeiten des Profils hinzufügen.

Für Linux-Systeme ist der gebräuchlichste Befehl zum Herunterladen des Inhalts Ihres öffentlichen SSH-Schlüssels:

cat ~/.ssh/id_rsa.pub

Dann müssen Sie im Bereich „Git-Zugriff“ zunächst einige notwendige Zustimmungen geben und den Benutzernamen und die E-Mail-Adresse konfigurieren, falls sie nicht die Standardprofildaten sind.

Nachdem Sie Zugriff auf das Versionskontrollsystem erhalten haben, können Ihre Änderungen bei der Arbeit an ausgewählten Repositories sowohl über eine öffentliche E-Mail-Adresse als auch über eine anonymisierte Adresse genehmigt werden, die vom drupal.org-Webportal bereitgestellt wird, z.B. [email protected].

2. Entwicklerbranch

Alle Contrib-Projekte sowie der Drupal-Kern halten sich an eine feste Versionsnummerierungskonvention. 
Für den Kern ist es z.B. (8.8.5), gemäß dem Schema:

[HAUPTVERSION].[NEBENVERSION].[PATCH]

Für Contrib-Projekte ist es z.B. (8.x-2.x), gemäß dem Schema:

[HAUPTVERSION DES KERNS].x-[MODULVERSION].x

Wenn Sie derzeit an der Version 1.15 des Moduls arbeiten, dann ist die Hauptversion der Branch und auch der Entwicklungsbranch der Branch: 8.x-1.x
Entwicklerbranchen erfordern kein zusätzliches „-dev“-Suffix oder das Hinzufügen eines Tags. Damit ein Entwicklungsbranch jedoch auf der Projektwebseite sichtbar ist, muss ein neues Release erstellt werden.

3. Erstellen von Vorveröffentlichungen und Veröffentlichungen

Wenn Sie der Meinung sind, dass das Projekt, an dem Sie arbeiten, Gestalt annimmt und immer mehr Funktionalitäten Ihre Ziele erfüllen, ist es gut, eine Vorveröffentlichung zu erstellen, die tatsächlich eine instabile Veröffentlichung ist.
Gemäß der angenommenen Konvention sollten solche Veröffentlichungen mit dem Suffix -[Typ][Nummer] versehen werden. Ihnen stehen diese Typen zur Verfügung:

• alpha,
• beta,
• rc (Release Candidate)

die sehr einfach definieren, wie nahe Ihr Projekt der Erreichung seiner Stabilität ist. Weitere Informationen zu diesem Thema finden Sie im Artikel Benennung von Veröffentlichungen.
Wenn Sie jedoch davon überzeugt sind, dass Ihr Modul vollständig stabil und gut getestet ist, können Sie eine stabile Version erstellen (ohne Suffix), z.B. 8.x-2.5.
Welchen Weg Sie auch wählen, Sie müssen zunächst ein Git-Tag hinzufügen, auf dessen Grundlage Ihre Veröffentlichung erstellt wird. Sie können dies mit dem Befehl tun:

git tag 8.x-1.1-alpha1

Anschließend müssen Sie die von Ihnen eingeführten Änderungen an das Repository senden:

git push origin 8.x-1.1-alpha1 - einzelnes Tag
git push origin --tags - alle Tags

Das auf diese Weise gesendete Tag kann jetzt verwendet werden, um eine neue Version zu erstellen (in der Projekterstellung – Veröffentlichungen/Neue Version hinzufügen).

Bitte beachten Sie, dass jedes Tag nur einmal verwendet werden kann und bereits verwendete Tags niemals aus dem Repository entfernt werden können (sie sind gesperrt).

Das Projekt pflegen

1. Fehlerliste

Hier lebt das Projekt wirklich. Hier werden alle Fehler, Verbesserungsvorschläge, neue Funktionen usw. gemeldet (eine Beispiel-Fehlerliste für das Droopler-Projekt). Jeder eingeloggte Benutzer des Webportals kann neue Fehler hinzufügen, kommentieren sowie Patches ausstellen.

Jeder Fehler hat einen Status, dessen Standardwert „Aktiv“ ist. Die vollständige Liste der Status finden Sie im Artikel Status-Einstellungen von Fehlern.

2. Patches ausstellen und annehmen

Patches können einem Fehler als Anhang in einem Kommentar hinzugefügt oder einem neu erstellten Fehler hinzugefügt werden. Die Liste der ausgestellten Patches finden Sie in der Zusammenfassung, unter dem ersten Beitrag in einem bestimmten Fehler.
Wenn ein Patch für Ihr Projekt ausgestellt wurde, sollten Sie diesen als Autor verifizieren und den Fehlerstatus entsprechend ändern. Wenn der vorgeschlagene Patch korrekt funktioniert, sollten Sie ihn übernehmen und den Autor des Patches ehren, indem Sie den Parameter --author hinzufügen, z.B.
 

git commit 
-m 'Issue #[Fehlernummer] von [Benutzername]: [Fehlertitel]' 
--author="Sayco <[email protected]>"

Falls Sie einen Fehler in der Funktionalität eines der Projekte oder des Drupal-Kerns selbst feststellen, können Sie auch Ihren eigenen Patch ausstellen. Um an einem solchen Patch zu arbeiten, müssen Sie mehrere Schritte unternehmen:

Sie klonen das Projekt-Repository (die Projektwebseite  – Code-Repository durchsuchen).

git clone [email protected]:project/paragraph_view_mode.git

Sie wechseln zu dem Branch, in dem der Fehler gefunden wurde, z.B.

git checkout 8.x-1.x

Nach den notwendigen Änderungen stehen Ihnen verschiedene Optionen zur Verfügung, um einen Patch zu erstellen. Wenn es nicht zu viele Änderungen gab und Sie sie nicht commiten mussten, generieren Sie einfach einen Patch basierend auf den aufgetretenen Unterschieden:

git diff > [projekt]-[beschreibung]-[fehlernummer]-[kommentarnummer].patch

Wenn es jedoch mehr Änderungen gab, können Sie je nach dem, was Sie erreichen möchten, einen Patch generieren, indem Sie Folgendes angeben: den Bereich der Commits, die einzelnen Commit-Hashes, die Anzahl der Commits für einen bestimmten Commit-Hash, z.B.

git format-patch -<n> <SHA1> 
--std-out > [projekt]-[beschreibung]-[fehlernummer]-[kommentarnummer].patch

Wie Sie sicher in den obigen Beispielen bemerkt haben, folgt der Patch-Name einem spezifischen Namenskonvention. Meistens geben Sie einer solchen Datei den Namen des Projekts, eine kurze Beschreibung, die Fehlernummer sowie die Kommentarnummer, in der der Patch ausgestellt wird.

Manchmal ist es zusätzlich zum Patch selbst erforderlich, einen Interdiff anzuhängen, d.h. eine Datei, die Unterschiede zwischen Ihrem Patch und z.B. einem zuvor gemeldeten Patch zeigt, auf dessen Grundlage Sie spezifische Änderungen eingeführt haben. Weitere Informationen zu diesem Thema finden Sie im Artikel „Erstellen eines Interdiffs"

3. Sicherheitsrichtlinie (Security Advisory Policy)

In einem bestimmten Stadium der Projektentwicklung können Sie schließlich sagen, dass es stabil und sicher genug ist, um sich für die SAP (Security Advisory Policy) zu bewerben. Es handelt sich um ein System mit offenen und öffentlichen Informationen über die Vorfälle im Drupal-Kern und in Contrib-Projekten. Die erkannten Vorfälle werden geheim gehalten (wenn möglich), bis ein Release mit einem entsprechenden Sicherheitspatch unter Unterstützung des Drupal Security Teams erstellt wird.

Die Projekte, die von SAP abgedeckt werden, erhalten ein Schildsymbol auf der Projektwebseite und einen grünen Hintergrund für alle stabilen Veröffentlichungen.
Dies lässt sie auf der Webseite hervortreten und erhöht den Wert dieser Projekte in den Augen potenzieller Benutzer.

3.1 Wie bewerben?

• Erstellen Sie ein neues Problem auf der Webseite https://www.drupal.org/project/issues/projectapplications.
• Definieren Sie den Titel gemäß dem Schema [KERNVERSION] [Modulname], z.B. [D8] Autotile.
• Setzen Sie den Fehlerstatus auf „Review erforderlich“.

3.2 Welche Anforderungen muss Ihr Projekt erfüllen?

• Es muss die Ziel-Funktionalitäten gemäß der Projektbeschreibung erfüllen.
• Es muss PAReview erfolgreich bestehen – ein Tool zur Online-Verifizierung von Drupal-Projekten.
• Es muss von der Community genehmigt werden (es handelt sich hauptsächlich um eine Verifizierung der Codequalität und Sicherheit).

Der Verifizierungsprozess ist einmalig für einen gegebenen Portalbenutzer. Nach der Genehmigung kann der Benutzer beliebig viele Projekte erstellen, die von SAP abgedeckt werden, ohne den Verifizierungsprozess durchlaufen zu müssen.

Zusammenfassung

Wie Sie sicher bemerkt haben, gibt es mehrere Möglichkeiten, zum Drupal-Community beizutragen. Sie können sowohl bestehende unterstützen als auch Ihre eigenen Projekte entwickeln und somit zur Entwicklung von Open-Source-Software beitragen. Ein gut gemachtes Modul kann von Ihnen und vielen anderen Benutzern in vielen Projekten immer wieder verwendet werden.

Ich denke, dass es für uns als Programmierer eine Art Mission oder eine Form des Zurückgebens an die Gemeinschaft für die Möglichkeit ist, freie Software für unseren eigenen Gebrauch zu nutzen. Natürlich ist es auch eine großartige Möglichkeit, Wissen, Erfahrungen auszutauschen und sich selbst zu promoten. Es ist erwähnenswert, dass Sie auf diese Weise nicht nur sich selbst, sondern auch die Organisation/Firma, für die Sie arbeiten, oder sogar die Kunden, für die Sie bestimmte Funktionen erstellen, promoten können. Ich entwickle bereits Projekte auf dem Drupal.org-Webportal. Sie können dies auch tun. Starten Sie heute!