(airflow) 01/01: Clarify assignment policy for issues

[po...@apache.org]

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 <ja...@potiuk.com>
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 <ht...@airflow.apache.org>`_ 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.
 
 -------------------------------