o-nikolas commented on code in PR #27103: URL: https://github.com/apache/airflow/pull/27103#discussion_r998526033
########## ISSUE_TRIAGE_PROCESS.rst: ########## @@ -151,11 +154,7 @@ to be able to reproduce the issue. Typically, this may require a response to the issue creator asking for more information, with the issue then being tagged with the label ``pending-response``. Also, during this stage, additional labels may be added to the issue to help -classification and triage, such as ``reported_version`` and ``area``. - -Occasionally an issue may require a larger discussion among the Airflow PMC or -the developer mailing list. This issue may then be tagged with the -``needs:discussion`` label. +classification and triage, such as ``affected_version`` and ``area``. Review Comment: We should decide (and then document here) if this label will be used to tag _all_ affected versions, or just the latest/most current affected version. The former seems like it'd be interesting data but lots of paperwork, the latter seems to be what we're most interested in (knowing how current an issue is). What do folks think? ########## ISSUE_TRIAGE_PROCESS.rst: ########## @@ -206,3 +204,11 @@ following situations: * Despite attempts to reproduce the issue to resolve it, the issue cannot be reproduced by the Airflow team based on the given information. In such cases, the issue is marked as ``Can't Reproduce``. * In some cases, the original creator realizes that the issue was incorrectly reported and then marks it as ``invalid``. Also, a committer could mark it as ``invalid`` if the issue being reported is for an unsupported operation or environment. * In some cases, the issue may be legitimate, but may not be addressed in the short to medium term based on current project priorities or because this will be irrelevant because of an upcoming change. The committer could mark this as ``wontfix`` to set expectations that it won't be directly addressed in the near term. + +**GitHub Discussions** + +Issues should represent clear feature requests which can/should be implemented. If the idea is vague or can be solved with easier steps +we normally convert such issues to category ideas in discussion. +Issues that seems more like support requests are also converted to discussion. +We use judgment about what issue to convert to discussion, it's best to always clarify with comment why the issue is converted. +Note that we can always convert discussion back to issue. Review Comment: ```suggestion Issues should represent clear feature requests which can/should be implemented. If the idea is vague or can be solved with easier steps we normally convert such issues to Discussions in the Ideas category. Issues that seems more like support requests are also converted to Discussions in the Q&A category. We use judgment about which Issues to convert to Discussions, it's best to always clarify with a comment why the Issue is being converted. Note that we can always convert Discussions back to Issues. ``` -- 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]
