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 [email protected].

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 du den Wunsch hast zu Firefox, Thunderbird oder Firefox OS beizutragen, kannst du unsere Sammlung von einfachen Schritten zur Komplilierung von Firefox, von Thunderbird oder von Firefox OS verwenden. Die Anleitung ist sehr zielstrebig, aber es braucht vielleicht etwas Zeit. In der Zwischenzeit kannst du dich schon mal mit dem nächsten Schritt befassen. Weiter Informationen dazu gibt es hier.

Für andere Produkte musst du möglicherweise garn nichts kompilieren.

Schritt 2 - Verstehen wie die Mitarbeit bei Mozilla funktioniert

Siehe die Seite Mozilla Firefox: Development Process. Bei Thunderbird gibt es einen ähnlichen Prozess.

Schritt 3 - 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 4 - 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:

Schau dir https://developer.mozilla.org/En/Developer_Guide an,
Frag in einem Kommentar zum Bug oder in #introduction bzw. #developers um Hilfe.

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.

Step 5 - Get your code reviewed

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.

Step 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.

Step 6 - Respond to the review

Often, a reviewer will ask for changes, perhaps minor, perhaps major. In either case, fix what the reviewer asks for; if you're unsure how, be sure to ask! Attach the new patch to the bug again, and ask for review again from the same reviewer. If they give you an r+ that means that your bug is accepted into the tree!

Step 7 - Actually get the code into the tree

Since you don't yet have the ability to push the code into the tree, you should ask somebody for help. If you have a mentor, ask them. If not, ask the reviewer. If the reviewer is too busy, mark that a commit is needed by adding the checkin-needed keyword. A friendly person should be along within a few days and push the code to the repository, and they will mark the bug as fixed.

Step 8 - Repeat

Congratulations, you've fixed your first bug. Now go back to step 3 and repeat. Now that you've got your first bug in, you should request level 1 access to the repository so that you can push to rhw tryserver and get automated feedback about your changes on multiple platforms. After fixing a nontrivial number of bugs, you should request level 3 access so that you can push your own code after it has been r+ed.

More information

We're in the process of improving information on this page for newcomers to the project. We'll be integrating some information from these pages soon, but until then you may find them interesting in their current form: