# So gelingt dein erster Beitrag zu einem Dekompilierungsprojekt

Author: DecompHub
Updated: 2026-10-10
Language: de
Canonical: https://decomphub.com/de/guides/contributing-to-decompilation

Wähle ein interessantes Ziel und eine überprüfbare Aufgabe. Dein erster Beitrag muss keine schwierige Funktion sein. Ein reproduzierbarer Build, eine präzisierte Voraussetzung oder ein guter Testbericht hilft den nächsten Mitwirkenden.

[Finde ein Projekt](/de/guides/finding-decompilation-projects) und richte Werkzeuge, Branches und Regeln nach dessen Dokumentation aus. DecompHub vermittelt keine Aufgaben und spricht nicht für die Verantwortlichen.

## Die Umgebung prüfen

[Ich kann helfen](https://app.decomphub.com/de/help) berücksichtigt macOS, Windows und Linux. Diese privaten Präferenzen unterstützen die Suche, garantieren aber keinen erfolgreichen Build.

Prüfe Betriebssystem, Compiler und Zielrevision. [Super Mario 64](https://github.com/n64decomp/sm64) unterscheidet Linux-, macOS- und Container-Abläufe sowie versionsabhängige Eingaben. Die Anleitung eines anderen Forks kann den falschen Ziel-Build erzeugen.

Halte Commit und Werkzeugversionen fest. Kläre Originaldaten und benötigte Hardware vor der Aufgabenwahl; das Verzeichnis stellt sie nicht bereit.

## Beitragsregeln lesen

Suche `CONTRIBUTING`, Projektdokumentation und Review-Ablauf. [GitHub erklärt, wo Beitragsrichtlinien erscheinen](https://docs.github.com/en/communities/setting-up-your-project-for-healthy-contributions/setting-guidelines-for-repository-contributors).

Möglicherweise sind ein vorheriges Issue, ein bestimmter Branch, Formatregeln oder Prüfkommandos vorgeschrieben. Beachte auch die Regeln zu KI-generierten Beiträgen. Eine gute erste Aufgabe hat ein klares Ende: erfolgreicher Build, passende Funktion, korrigierte Anleitung oder reproduzierter Fehler.

## Einen Ausgangszustand sichern

Führe die dokumentierte Prüfung vor Änderungen aus und notiere Kommando, Ziel, Werkzeuge und Ergebnis. Scheitert bereits der Ausgangsstand, behandle das getrennt.

Ein Fehlerbericht beschreibt erwartetes und tatsächliches Verhalten sowie minimale Reproduktionsschritte. Beschränke Logs auf Relevantes. Eine genaue Angabe zu Kommando, Schritt und Toolchain ist hilfreicher als „funktioniert nicht“.

## Beiträge mit Nachweis

- **Dokumentation:** einen selbst getesteten Schritt, eine Voraussetzung oder einen offiziellen Link korrigieren.
- **Tests:** ein veröffentlichtes Verfahren auf verfügbarer Hardware ausführen und Version sowie Ergebnis festhalten.
- **Matching-Code:** mit einer kleinen verstandenen Funktion beginnen. [decomp.me](https://www.decomp.me/faq) erlaubt Compilerexperimente; anschließend gelten die Prüfungen des Projekts.
- **Werkzeuge:** einen wiederholbaren Ablauf oder eine Fehlermeldung verbessern, ohne etablierte Kontrollen zu verändern.

[objdiff](https://github.com/encounter/objdiff) erklärt einen weiteren Vergleichsablauf. Nutze die vorgeschriebenen Werkzeuge, statt aus Gewohnheit einen zweiten Stapel einzuführen.

## Einen begrenzten Änderungsvorschlag machen

Beschreibe Problem, Ergebnis und Prüfung. Nenne beim Matching Ziel und Vergleich, bei Dokumentation die getesteten Schritte. Sage ausdrücklich, was ungetestet bleibt.

Vermeide eine allgemeine Aufräumaktion neben der eigentlichen Aufgabe. Kleine belegte Änderungen erleichtern die Prüfung. Bei stillen oder archivierten Repositories suche einen dokumentierten Nachfolger, bevor du Feedback erwartest.

[Reiche die offizielle URL ein](https://app.decomphub.com/de/submit), falls das Projekt fehlt. Der [Fortschrittsleitfaden](/de/guides/understanding-decompilation-progress) hilft beim Lesen seiner Messwerte.