Zum Code von Mozilla beitragen

Diese Seite soll dich durch durch die ersten Schritte führen, die nötig sind um bei Mozilla mitzuwirken. Wilkommen, wir freuen uns, dich zu sehen :)

Brauchst du Hilfe?

Die Mozilla Gemeinschaft begrüsst immer Anfänger in ihrer Mitte. Wenn du Schwierigkeiten hast, dann kannst du Fragen im #introduction chat room auf irc.mozilla.org(englisch) stellen. Wenn du immer noch Probleme haben solltest, dann sende eine E-mail an Kyle Huey auf khuey@mozilla.com.

Welche Fähigkeiten brauche ich?

Mozilla ist ein großes Projekt und wir sind froh darüber, wenn es Mitwirkende mit sehr unterschiedlichen Fähigkeiten gibt.

  • Wenn du C++ kannst, kannst du zum Beispiel am Kern von Firefox, Firefox OS und anderen Mozilla-Produkten mitarbeiten.
  • Wenn du JavaScript oder HTML/CSS kannst, kannst du am front-end von Firefox, oder an Gaia, der Anwendungsebene von Firefox OS mitarbeiten.
  • Wenn du Java kannst, kannst du an Firefox Mobile mitarbeiten.
  • Wenn du Python kannst, kannst du zu unseren Web-Anwendungen , eingeschlossen Firefox Sync oder Persona beitragen.
  • Wenn du mit Make, shell, Perl oder Python umgehen kannst, kannst du an unserem  build System mitarbeiten.
  • Wenn du C kannst, kannst du bei einer Vielzahl von low-level und Drittanbieter-Bilbiotheken mitarbeiten, die wir als Teil des Mozilla Codes verwenden.
  • Außerdem gibt es viele Wege um mitzuhelfen, ohne dass man Programmieren können muss. Wenn du gerne bei Design, Support, Übersetzung, Testen oder anderen Tätigkeiten mithelfen willst, informiere dich auf der Seite Volunteer Opportunities.

Vielleicht kannst du noch nicht Programmieren, willst es aber lernen? Das ist großartig und das Webmaker Programm ist das richtige für dich. Außerdem findest du weitere Informationen im Mozilla Developer Network!

Schritt 1 - Firefox, Firefox OS, Thunderbird oder eine andere Anwendung kompilieren

Wenn Sie einen Beitrag zu Firefox leisten möchten, finden Sie hier einfache Anweisungen zum Erstellen von Desktop- oder Mobil-Firefox. Das Einrichten kann einige Zeit in Anspruch nehmen, da einige große Downloads erforderlich sind. Daher möchten Sie möglicherweise mit den nächsten Schritten fortfahren, während das Programm erstellt wird. Zusätzliche Bauanleitungen finden Sie hier.

Die anderen Mozilla-Produkte, einschließlich der von der Community unterstützten Thunderbird-Builds, können mit einer schnellen Suche gefunden werden. Oft müssen Sie nichts bauen, um einen Beitrag zu leisten.

Schritt 2 - Etwas finden, um daran zu arbeiten

Fang mit dem an, was dich am meisten ärgert

Wenn es etwas gibt, dass du an Firefox, Thunderbird oder einer anderen deiner liebsten Mozilla-Anwendungen verbessern oder reparieren möchtest, wäre das ein guter Anfang. Es gibt mehrere Wege, dies zu tun:

  • Durchsuche Bugzilla nach Schlüsselwörtern,
  • Finde heraus, in welcher Komponente dein Ärgernis implementiert wurde, indem du die Liste der Komponenten der jeweiligen Anwendung durchsuchst. Suche auf Bugzilla nach ähnlichen Bugs.
  • Frag' nach bei #introduction oder #developers auf irc.mozilla.org.

Finde einen Bug, der gut für Neuankömmlinge ist

Mozilla-Entwickler markieren bestimmte Bugs als gut geeignet, um Neuankömmlinge mit unseren Prozessen vertrautzumachen.

  • Betreute Bugs kommen mit einem Mentor daher, der anbietet, dir bei jedem deiner Schritte behilflich zu sein. Normalerweise solltest du genug Informationen über den Bug vorfinden, um loslegen zu können. Wann auch immer du Hilfe brauchst, kontaktierst du einfach den Mentor über IRC, beim Bug selber oder per E-Mail. Sobald du deinen Bugfix fertiggestellt hast, wird er dir helfen, deinen Code in den Tree zu bekommen.
  • "Gute" erste Bugs sind vielleicht ein bisschen abgestanden, aber an irgendeinem Punkt während ihres Daseins wurde entschieden, dass sie gut für Neueinsteiger wären. Wir sind dabei, diese Bugs in Betreute Bugs umzuwandeln, aber neuere "Gute Erste Bugs" können gute Startpunkte sein, wenn du keine passenden betreuten Bugs findest.
  • Studentenprojekte sind größere Projekte, die vielleicht etwas für einen Studenten sind, der sich etwas dazuverdienen möchte. Natürlich kannst du dich diesen Bugs auch annehmen, wenn du kein Student bist. Wir pflegen zwei Listen, eine für Projekte, die auf existierendem Code basieren und eine um neue Anwendungen zu impementieren.

Schritt 3 - Den Bug fixen

Wir übergeben dies in deine fähigen Hände. Natürlich haben wir hier auch ein paar Ressourcen, um dir dabei zu helfen:

Wenn es wahrscheinlich ist, dass die Dokumentation ein Update benötigt, wenn du mit dem Bugfix fertig bist, versicher dich, das dev-doc-needed Schlüsselwort zum Bug hinzuzufügen (oder frag jemanden, ob er das für dich tun könnte, wenn du nicht die nötigen Privilegien hast.). Das bringt deinen Bug auf den Radar unseres Dokumentationsteams, die Dokumentaion wird baldesmöglich erneuert. Wenn du den Bug nicht markierst, könnte er vom Dokumentationsteam übersehen werden! Du kannst den Bug wann immer du willst mit diesem Schlüsselwort markieren; du brauchst nicht zu warten, bis er wirklich repariert ist.

Natürlich, unsere Dokumentation ist ein Wiki; Du kannst wirklich helfen, indem du die Dokumentation selber auf dem neuesten Stand hälst. Selbst wenn du nicht mit deinen Schreibfähigkeiten zufrieden bist, denke daran, das du hilfreich bist, fröhliche Wichtel aus dem Dokumentationsteam werden dir folgen und hinter dir aufräumen.

Schritt 4 - Lassen Sie Ihren Code überprüfen

Once you fix the bug, attach a patch to the bug, and ask for review. Do this by clicking the Details link on your attachment, then setting the review flag to ? and entering the reviewer's bugzilla ID in the text field that appears (either their email address of the :UniqueName they provide). It is very important to attach a bugzilla ID, or the request will be missed. So how do you figure out the right person to ask for a review?

  • If you have a mentored bug, ask your mentor, they will know or can find out easily.
  • Run hg blame and look at the people who have touched the function's you've worked on - they will be a good candidate.
  • The bug itself may contain a clear indication of the best person to ask for a review.
  • Are there related bugs on similar topics? In that case, the reviewer in those bugs might be a good choice.
  • We have an out of date list of modules which lists peers and owners for the module, some of whom will be a good reviewer. In the worst case, set the module owner as the reviewer, and ask them in the comment to pick someone better if they don't have time.

Schritt 5b - Follow it up

If you've asked for review, but the reviewer hasn't said anything for a few days, don't be afraid to ping them. Just add a comment to the bug saying 'review ping?', and another a few days later if they still haven't responded. If they don't respond after that, ask for help in #introduction or #developers.

Schritt 5 - Beantworten Sie die Bewertung

Oft fordert ein Rezensent Änderungen an, die geringfügig oder erheblich sein können. Beheben Sie in beiden Fällen, was der Prüfer verlangt. Wenn Sie sich nicht sicher sind, wie, fragen Sie auf jeden Fall! Hängen Sie den neuen Patch erneut an den Fehler an und bitten Sie denselben Prüfer erneut um Überprüfung. Wenn sie dir ein R + geben, bedeutet das, dass dein Fehler in den Baum aufgenommen wird!

Schritt 6 - Holen Sie sich tatsächlich den Code in den Baum

Da Sie den Code noch nicht in den Baum schreiben können, sollten Sie jemanden um Hilfe bitten. Wenn Sie einen Mentor haben, fragen Sie ihn. Wenn nicht, fragen Sie den Prüfer. Wenn der Prüfer zu beschäftigt ist, markieren Sie, dass ein Commit erforderlich ist, indem Sie das Schlüsselwort checkin-needed hinzufügen. Eine freundliche Person sollte innerhalb weniger Tage anwesend sein und den Code an das Repository senden, und sie wird den Fehler als behoben markieren.

Schritt 7 - Wiederholen

Vielen Dank! Sie haben Ihren allerersten Fehler behoben und das Open Web ist dafür stärker. Aber hör jetzt nicht auf.

Kehren Sie zu Schritt 3 zurück, da noch viel zu tun ist. Ihr Mentor schlägt möglicherweise einen neuen Fehler vor, an dem Sie arbeiten können, oder sucht einen, der Sie interessiert. Nachdem Sie Ihren ersten Fehler behoben haben, sollten Sie den Zugriff auf das Repository der Ebene 1 anfordern, um einen Push an den Try-Server zu senden und automatisiertes Feedback zu Ihren Änderungen auf mehreren Plattformen zu erhalten. Nachdem Sie eine nicht unerhebliche Anzahl von Fehlern behoben haben, sollten Sie den Zugriff auf Stufe 3 anfordern, damit Sie nach der Überprüfung Ihren eigenen Code erhalten können.

Mehr Informationen

Wir sind dabei, Informationen auf dieser Seite für Neulinge des Projekts zu verbessern. Wir werden in Kürze einige Informationen von diesen Seiten integrieren, aber bis dahin könnten Sie sie in ihrer aktuellen Form interessant finden: