Miretpl commented on code in PR #62417: URL: https://github.com/apache/airflow/pull/62417#discussion_r2848908082
########## 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>`_ +Issue reporting and resolution process +====================================== + +.. 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 is fine:** Multiple people can work on the same issue and it's fine while not necessarily + default. When it happens - we will merge the best implementation, and encourage 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. -Fix Bugs --------- +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>`_. -Look through the GitHub issues for bugs. Anything is open to whoever wants to implement it. +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. -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 -`Devlist <https://lists.apache.org/[email protected]>`_ instead. +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 Review Comment: ```suggestion The "no assignment" policy is not intended to discourage contributors — quite the opposite. We ``` ########## 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>`_ +Issue reporting and resolution process +====================================== + +.. 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 is fine:** Multiple people can work on the same issue and it's fine while not necessarily + default. When it happens - we will merge the best implementation, and encourage 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. -Fix Bugs --------- +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>`_. -Look through the GitHub issues for bugs. Anything is open to whoever wants to implement it. +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. -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 -`Devlist <https://lists.apache.org/[email protected]>`_ instead. +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. Review Comment: ```suggestion * Users attempt to use Gen-AI to solve the issue and fail to deliver or lose interest. ``` ########## 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>`_ +Issue reporting and resolution process +====================================== + +.. 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 is fine:** Multiple people can work on the same issue and it's fine while not necessarily + default. When it happens - we will merge the best implementation, and encourage 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. -Fix Bugs --------- +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>`_. -Look through the GitHub issues for bugs. Anything is open to whoever wants to implement it. +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. -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 -`Devlist <https://lists.apache.org/[email protected]>`_ instead. +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. This often prevents others from working on them in parallel. + +Working in parallel on the same issue is fine, while not default. While this might lead to +several PRs fixing the same issue, we will merge the best implementation and close the others +and we encourage cooperation and learning from each other in the process. This is a positive outcome, +as it allows contributors to: Review Comment: ```suggestion Working in parallel on the same issue is fine, but not the default. When this leads to several PRs fixing the same issue, we will merge the best implementation and close the others, and we encourage cooperation and learning from each other in the process. This is a positive outcome, as it allows contributors to: ``` ########## 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>`_ +Issue reporting and resolution process +====================================== + +.. 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 is fine:** Multiple people can work on the same issue and it's fine while not necessarily + default. When it happens - we will merge the best implementation, and encourage 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. -Fix Bugs --------- +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>`_. -Look through the GitHub issues for bugs. Anything is open to whoever wants to implement it. +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. -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 -`Devlist <https://lists.apache.org/[email protected]>`_ instead. +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 Review Comment: ```suggestion that they are "working on it", but we will not formally assign them. We used this system ``` ########## 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>`_ +Issue reporting and resolution process +====================================== + +.. 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 is fine:** Multiple people can work on the same issue and it's fine while not necessarily + default. When it happens - we will merge the best implementation, and encourage 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. -Fix Bugs --------- +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>`_. -Look through the GitHub issues for bugs. Anything is open to whoever wants to implement it. +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. -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 -`Devlist <https://lists.apache.org/[email protected]>`_ instead. +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." Review Comment: ```suggestion * Users treat assignment as a "badge". ``` -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
