An Qiskit mitwirken

Qiskit ist ein Open-Source-Projekt mit dem Ziel Menschen aller Alters- und Berufsgruppen die Nutzung von Quanteninformationstechnologien zu ermöglichen. Diese Seite beschreibt wie man sich der Qiskit-Gemeinschaft anschließen kann.

Before You Start

If you are new to Qiskit contributing we recommend before diving in to the code you should do the following:

  1. Read the Code of Conduct

  2. Decide what to work on

  3. Read the repo-specific Contributing Guidelines for the repo you have decided to contribute to.

  4. Set up your development environment

  5. Familiarize yourself with the Qiskit community (via Slack, Stack Exchange, GitHub etc.)

Decide What to Work on

If you’re not sure what type of contribution is right for you, take a look at the following flowchart to help you:

Report/fix typos, broken links etc. in the relevant package or textbook repo Documentation: Answer questions in , , or Help others in the community! Slack StackExchange Twitter other channels Check out the Translations: repo qiskit-community/qiskit-translations Looking to contribute to Qiskit? I’m not sure how yet but I want to get involved! Is there already a GitHub issue open for this bug? Would you like to code? Which programming language are you most comfortable with? Rust , Take a look at: retworkx qiskit-terra Take a look at: qiskit-aer , Take a look at: platypus , , , , , , , Take a look at: qiskit-terra qiskit-nature qiskit-finance qiskit-optimization qiskit-machine-learning qiskit-experiments qiskit-dynamics qiskit-metal C++ Javascript/web dev. Python Consider the following options: I’d like to report a bug I have an idea for a feature I have some code for this feature It’s just an idea Do you know which Qiskit package you would like your feature added to? Yes No Yes No work is in scope work is not in scope Discuss your idea with maintainers Work with maintainers to integrate your feature into Qiskit Consider creating a standalone module and join the Qiskit Ecosystem Open a feature request GitHub issue Open a GitHub discussion in the repo qiskit-community/feedback Yes No Open an issue with a minimum reproducible code example Leave a comment or +1 in the issue (with a code example even better!) If you would like to work on this issue, leave a comment in the issue requesting to be assigned Get coding and open a PR! Choose the repo you want to work on, look at the open issues in the issues tab, look for issues with "good first issue" or "help wanted" labels

Contributing to a Specific Repo

Each Qiskit package has its own set of Contributing Guidelines (kept in the file) which details specific information on contributing to that repository. Make sure you read through the repo-specific Contributing Guidelines prior to making your contribution to a specific repo as each project may have slightly different requirements and processes.


Contributing Guidelines

Qiskit Terra

Qiskit Aer

Qiskit Nature

Qiskit Machine Learning

Qiskit Finance

Qiskit Optimization

Qiskit Experiments

Qiskit Dynamics

Qiskit Metal

Qiskit Textbook (legacy)

Qiskit Textbook (beta)

Qiskit Tutorials


Qiskit (meta-package)

Set up Your Development Environment

To get started contributing to the Python-based Qiskit repos you will need to set up a Python Virtual Development Environment and install the appropriate package from source.

For a quick guide on how to do this for qiskit-terra take a look at the How to Install Qiskit - Contributors YouTube video.

You can learn how to install different Qiskit packages from source in the install-from-source.

For non-python packages you should check the file for specific details on setting up your dev environment.

Set up Python Virtual Development Environment

Für die Qiskit-Entwicklung werden Virtuelle Umgebungen verwendet, um die Entwicklungsumgebung von systemweiten Paketen zu isolieren. Auf diese Weise wird eine ungewollte Abhängigkeit von einer bestimmten Systemkonfiguration vermieden. Dies macht es für Entwickler auch einfach, mehrere Umgebungen zu verwalten (z. B. eine pro unterstützte Python-Version, für ältere Versionen von Qiskit, etc.).

All Python versions supported by Qiskit include built-in virtual environment module venv.

Start by creating a new virtual environment with venv. The resulting environment will use the same version of Python that created it and will not inherit installed system-wide packages by default. The specified folder will be created and is used to hold the environment’s installation. It can be placed anywhere. For more detail, see the official Python documentation, Creation of virtual environments.

python3 -m venv ~/.venvs/qiskit-dev

Activate the environment by invoking the appropriate activation script for your system, which can be found within the environment folder. For example, for bash/zsh:

source ~/.venvs/qiskit-dev/bin/activate

Upgrade pip within the environment to ensure Qiskit dependencies installed in the subsequent sections can be located for your system.

pip install -U pip

For Conda users, a new environment can be created as follows.

conda create -y -n QiskitDevenv python=3
conda activate QiskitDevenv
pip install -e .


Wir verwenden GitHub Pull-Requests um Beiträge zu akzeptieren.

Obwohl nicht zwingend benötigt sollte ein Issue bzgl. dem Bug oder dem Feature an welchem man arbeitet vor dem Pull Request geöffnet werden. Dies ist ein wichtiger Schritt um die Diksussion mit der Community bzgl. der Änderungen zu beginnen. Mit einem Issue wird es ermöglicht die Idee zu besprechen und zu erörtern wie entsprechender Code implementiert werden muss. Des Weiteren kann so die Community erfahren an was man gerade arbeitet, ob Hilfe benötigt wird, und zusätzlich kann man auf das Issue in Diskussionen referenzieren.

If you’ve written some code but need help finishing it, want to get initial feedback on it prior to finishing it, or want to share it and discuss prior to finishing the implementation, you can open a Draft pull request and prepend the title with the [WIP] tag (for Work In Progress). This will indicate to reviewers that the code in the PR isn’t in its final state and will change. It also means that we will not merge the commit until it is finished. You or a reviewer can remove the [WIP] tag when the code is ready to be fully reviewed for merging.

Before marking your Pull Request as „ready for review“ make sure you have followed the PR Checklist below. PRs that adhere to this list are more likely to get reviewed and merged in a timely manner.

Pull Request Checklist:

  • You have followed the requirements in the file for the specific repo you are contributing to.

  • All CI checks pass (it’s recommended to run tests and lint checks locally before pushing).

  • New tests have for any new functionality that has been introduced.

  • The documentation has been updated accordingly for any new/modified functionality.

  • A release note has been added if the change has a user-facing impact.

  • Any superfluous comments or print statements have been removed.

  • All contributors have signed the Contributor License Agreement (Mitwirkenden-Lizenzvereinbarung).

  • The PR has a concise and explanatory title (e.g. Fixes Issue1234 is a bad title!).

  • If the PR addresses an open issue the PR description includes the fixes #issue-number syntax to link the PR to that issue (you must use the exact phrasing in order for GitHub to automatically close the issue when the PR merges)


Code review is done in the open and is open to anyone. While only maintainers have access to merge commits, community feedback on pull requests is extremely valuable. It is also a good mechanism to learn about the code base.

Response times may vary for your PR, it is not unusual to wait a few weeks for a maintainer to review your work, due to other internal commitments. If you have been waiting over a week for a review on your PR feel free to tag the relevant maintainer in a comment to politely remind them to review your work.

Please be patient! Maintainers have a number of other priorities to focus on and so it may take some time for your work to get reviewed and merged. PRs that are in a good shape (i.e. following the Pull Request Checklist:) are easier for maintainers to review and more likely to get merged in a timely manner. Please also make sure to always be kind and respectful in your interactions with maintainers and other contributors, you can read the Qiskit Code of Conduct.

Contributor License Agreement (Mitwirkenden-Lizenzvereinbarung)

Bevor neuer Code beigesteuert werden kann müssen alle Mitwirkenden die „Contributer License Agreement“ (CLA) (Mitwirkenden-Lizenvereinbarung) unterscheiben. Mit dem Unterzeichnen der CLA bestätigt man, dass man Autor des Code-Beitrags ist, und dass man diesen unentgeltlich entsprechend der Apache-2.0 Lizenz beisteuert.

Wenn man an einem Qiskit-Projekt mit einem Pull-Request mitwirkt prüft ein Bot ob die CLA unterzeichnet wurde. Falls nötig wird der Bot den Pull-Request kommentieren - inklusive eines Links zum Akzeptieren der Vereinbarung. Die CLA für natürliche Personen ist zur Überprüfung als PDF-Datei verfügbar.


Falls ein Beitrag einem Beschäftigungsverhältnis entstammt oder Eigentum des Arbeitgebers ist, ist es sehr wahrscheinlich, daß eine CLA für Unternehmen unterzeichnet werden muss, und per E-Mail an <> geschickt werden muss.