shahar1 commented on code in PR #62417: URL: https://github.com/apache/airflow/pull/62417#discussion_r2849394218
########## 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 Review Comment: "...unless maintainers know them" (consistent with the statement below and the discussion in dev list) ########## 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. Review Comment: tl;dr/post-writing comment: If this line is intended only at "uncertain bugs", please clarify it (otherwise, please read the long part). Also, if we plan to use the GitHub discussions more extensively, all maintainers/triagers should be aligned. ---- I don't feel comfortable with this specific statement. When people indicate a *real* reproducible bug or have a valid feature request, I don't see a reason to first consider doing it within a GitHub discussion - as it is not intended for that purpose and will be harder to track. Also, currently GitHub discussions is a blind spot for most maintainers as well. If it's "something that seems like a bug, but uncertain" - then maybe GitHub discussions is a more suitable for that, but I didn't get the impression from the discussion on dev list that committers/triagers are well-aware that this section should be on their radar from now on. What I think that should be done instead, considering the context of the discussion on the dev. thread list: 1. We should be stricter with the requirement for reproduction steps when reporting bugs, and refer non-reproducible ones to the discussion section. 2. If we do want to encourage usage of GitHub discussions, for whatever purpose, it should be clarified for maintainers/triagers that they should track it as well. ########## 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 Review Comment: What if the author doesn't have the abilities/resources to implement the feature by themselves? Do we want in this case to avoid it in the Issues section at all? Should they open it in the discussions? It's not as clear from current wording. -- 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]
