This is an automated email from the ASF dual-hosted git repository. potiuk pushed a commit to branch clarify-assignment-policy in repository https://gitbox.apache.org/repos/asf/airflow.git
commit 54d40ad1b2d8b948d4d53039aca5a49c5752f798 Author: Jarek Potiuk <[email protected]> AuthorDate: Tue Feb 24 17:41:12 2026 +0100 Clarify assignment policy for issues Those changes describe the way we change our approach for assigning issues and explaining why we are doing it. --- contributing-docs/04_how_to_contribute.rst | 129 +++++++++++++++++++++-------- 1 file changed, 94 insertions(+), 35 deletions(-) diff --git a/contributing-docs/04_how_to_contribute.rst b/contributing-docs/04_how_to_contribute.rst index e9b470eda0b..7cb04af4b43 100644 --- a/contributing-docs/04_how_to_contribute.rst +++ b/contributing-docs/04_how_to_contribute.rst @@ -36,53 +36,111 @@ Report security issues If you want to report a security finding, please follow the `Security policy <https://github.com/apache/airflow/security/policy>`_ +Since the original text was written for Apache Airflow (which primarily uses Sphinx and +reStructuredText for documentation), converting it back to .rst ensures all the cross-references +and formatting match their existing standards. -Fix Bugs --------- - -Look through the GitHub issues for bugs. Anything is open to whoever wants to implement it. - +Here is the corrected version in reStructuredText format: Issue reporting and resolution process --------------------------------------- - -An unusual element of the Apache Airflow project is that you can open a PR to -fix an issue or make an enhancement, without needing to open an issue first. -This is intended to make it as easy as possible to contribute to the project. - -If you however feel the need to open an issue (usually a bug or feature request) -consider starting with a `GitHub Discussion <https://github.com/apache/airflow/discussions>`_ instead. -In the vast majority of cases discussions are better than issues - you should only open -issues if you are sure you found a bug and have a reproducible case, -or when you want to raise a feature request that will not require a lot of discussion. -If you have a very important topic to discuss, start a discussion on the +====================================== + +.. note:: + **TL;DR: Quick Summary** + + * **No Issue Needed:** You can open a PR directly without opening an issue first. + * **Discussion First:** If you aren't sure about a bug or feature, start a + `GitHub Discussion <https://github.com/apache/airflow/discussions>`_ instead. + * **No Assignments:** we do **not** assign issues to non-maintainers. Please do not ask to + be assigned; simply comment "working on it" and submit your PR. + * **Parallel Work Welcome:** Multiple people can work on the same issue. We merge the best + implementation, which encourages learning and community feedback. + +An unusual element of the Apache Airflow project (compared, for example, to commercial +development) is that you can open a PR to fix an issue or make an enhancement without needing +to open an issue first. This is intended to make it as easy as possible to contribute to the +project. + +If you feel the need to open an issue (usually a bug or feature request), consider starting +with a `GitHub Discussion <https://github.com/apache/airflow/discussions>`_ instead. + +In the vast majority of cases, discussions are better than issues. You should only open an +issue if you are certain you have found a bug with a reproducible case, or when you want to +raise a feature request that will not require extensive discussion. If you have a significant +topic to discuss, start a thread on the `Devlist <https://lists.apache.org/[email protected]>`_ instead. -The Apache Airflow project uses a set of labels for tracking and triaging issues, as -well as a set of priorities and milestones to track how and when the enhancements and bug -fixes make it into an Airflow release. This is documented as part of -the `Issue reporting and resolution process <../ISSUE_TRIAGE_PROCESS.rst>`_, +The Apache Airflow project uses a set of labels for tracking and triaging issues, as well as +a set of priorities and milestones to track how and when enhancements and bug fixes make it +into an Airflow release. This is documented as part of the +`Issue reporting and resolution process <../ISSUE_TRIAGE_PROCESS.rst>`_. -Implement Features ------------------- +Contribute code changes +----------------------- + +Note that we do not usually assign issues to people. Maintainers only self-assign issues when +they want to ensure they are working on something where they have unique knowledge or a +specific desire to work on a specific part. + +As of **March 2026**, we do not expect people to ask to be assigned to issues, and we will +not assign them when asked. Contributors are still welcome to work on those issues and comment +that they are "working on it," but we will not formally assign them. We used this system +previously, but found it did not work well in a landscape where: + +* Users treat assignment as a "badge." +* Users are unsure if they can follow through on the work. +* Users attempt to use Gen-AI to solve the issue but fail to deliver or lose interest. + +Consequently, we do not assign issues to anyone who is not a maintainer, unless a maintainer +knows them personally and has agreed to the work via direct communication. + +The "no assignment" policy is not intended to discourage contributors—quite the opposite. We +want to ensure we do not have a backlog of "assigned" issues that are not actually being +addressed, which prevents others from working on them in parallel. -Look through the `GitHub issues labeled "kind:feature" -<https://github.com/apache/airflow/labels/kind%3Afeature>`__ for features. +Working in parallel on the same issue is not a problem. While this might lead to several PRs +fixing the same issue, we will merge the best implementation and close the others. This is a +positive outcome, as it allows contributors to: + +1. Receive feedback on their implementation. +2. Learn from different perspectives and coding styles. +3. Foster community building. + +Any feature or bug request is open to whoever wants to address it, even if someone else has +already commented or submitted a linked PR. If you wish to contribute to an issue that already +has an open PR, you are encouraged to review that PR and help lead it to completion. However, +it is also perfectly fine to submit your own PR if your solution is different. We embrace this +"better PR wins" approach as the most effective way to encourage learning and ensure the best +result for the project. + +Fix Bugs +........ + +Look through the `GitHub issues labeled "kind:bug" <https://github.com/apache/airflow/labels/kind%3Abug>`__ +for features. + +Look through the GitHub issues for bugs. Anything is open to whoever wants to implement it. Easy to fix +bugs are usually marked with the ``good first issue`` label, but you can also look for other issues +that are not marked as ``good first issue`` - they might be still easy to fix, and they might be a good way +to get started with the project. + +Implement Features +.................. -Any unassigned feature request issue is open to whoever wants to implement it. +Look through the `GitHub issues labeled "kind:feature" <https://github.com/apache/airflow/labels/kind%3Afeature>`__ +for features. -We've created the operators, hooks, macros and executors we needed, but we've -made sure that this part of Airflow is extensible. New operators, hooks, macros -and executors are very welcomed! +We've created the operators, hooks, macros and executors we needed, but we've made sure that this part of +Airflow (providers) is easily extensible. New operators, hooks, macros and executors are very welcome! Improve Documentation --------------------- -Airflow could always use better documentation, whether as part of the official -Airflow docs, in docstrings, ``docs/*.rst`` or even on the web as blog posts or -articles. +Airflow could always use better documentation, whether as part of the official Airflow docs, in docstrings, +``/docs/`` folders in the projects or even on the web as blog posts or articles. -See the `Docs README <https://github.com/apache/airflow/blob/main/docs/README.md>`__ for more information about contributing to Airflow docs. +See the `Docs README <https://github.com/apache/airflow/blob/main/docs/README.md>`__ for more information +about contributing to Airflow docs. Submit Feedback --------------- @@ -93,8 +151,9 @@ If you are proposing a new feature: - Explain in detail how it would work. - Keep the scope as narrow as possible to make it easier to implement. -- Remember that this is a volunteer-driven project, and that contributions are - welcome :) +- Remember that this is a volunteer-driven project, and that contributions are welcome, and sometimes + the fastest way to get a new feature implemented/bug fixed is to implement it yourself and submit a + PR for it. -------------------------------
