potiuk commented on code in PR #62417: URL: https://github.com/apache/airflow/pull/62417#discussion_r2848695661
########## contributing-docs/04_how_to_contribute.rst: ########## @@ -36,53 +36,115 @@ 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>`_. + +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. + +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 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 ------------------- +.................. -Look through the `GitHub issues labeled "kind:feature" -<https://github.com/apache/airflow/labels/kind%3Afeature>`__ for features. +Look through the `GitHub issues labeled "kind:feature" <https://github.com/apache/airflow/labels/kind%3Afeature>`__ +for features. -Any unassigned feature request issue is open to whoever wants to implement it. +Anything is open to whoever wants to implement it. Easy to fix features are usually marked with the Review Comment: ups. Copy& paste -- 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]
