o-nikolas commented on code in PR #27262: URL: https://github.com/apache/airflow/pull/27262#discussion_r1004732184
########## COMMITTERS.rst: ########## @@ -75,7 +75,8 @@ Code contribution Community contributions ^^^^^^^^^^^^^^^^^^^^^^^^ -1. Was instrumental in triaging issues +1. Actively participated in in `triaging issues <ISSUE_TRIAGE_PROCESS.rst>`_ showing their understanding Review Comment: ```suggestion 1. Actively participated in `triaging issues <ISSUE_TRIAGE_PROCESS.rst>`_ showing their understanding ``` ########## ISSUE_TRIAGE_PROCESS.rst: ########## @@ -30,6 +30,53 @@ 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. +Another important part of our Issue reporting process are also Github Discussions. +Issues should represent clear feature requests which can/should be implemented. +Users are encouraged to open Discussions rather than Issues if there are no clear, reproducible +steps, or when they have troubleshooting problems. + +Responding to issues/discussions (relatively) quickly +''''''''''''''''''''''''''''''''''''''''''''''''''''' + +It is vital to provide rather quick feedback to Issues and Discussions opened by our users, so that they +feel listened to rather than ignored. Even if the response is "we are not going to work on it because ...", +or "converting this issue to discussion because ..." or "closing because it is a duplicate of #xxx", it is +far more welcoming than leaving issues and discussions unanswered. Sometimes issues and discussions are +answered by other users (and this is cool) but if an issue/discussion is not responded to for few days or Review Comment: ```suggestion answered by other users (and this is cool) but if an issue/discussion is not responded to for a few days or ``` ########## ISSUE_TRIAGE_PROCESS.rst: ########## @@ -30,6 +30,53 @@ 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. +Another important part of our Issue reporting process are also Github Discussions. +Issues should represent clear feature requests which can/should be implemented. +Users are encouraged to open Discussions rather than Issues if there are no clear, reproducible +steps, or when they have troubleshooting problems. + +Responding to issues/discussions (relatively) quickly +''''''''''''''''''''''''''''''''''''''''''''''''''''' + +It is vital to provide rather quick feedback to Issues and Discussions opened by our users, so that they +feel listened to rather than ignored. Even if the response is "we are not going to work on it because ...", +or "converting this issue to discussion because ..." or "closing because it is a duplicate of #xxx", it is +far more welcoming than leaving issues and discussions unanswered. Sometimes issues and discussions are +answered by other users (and this is cool) but if an issue/discussion is not responded to for few days or +weeks, this gives an impression, that the user reporting it is ignored, that creates an impression of +non-welcoming project. + +We strive to provide relatively quick responses to all such issues and discussions. Users should exercise +patience while waiting for those (knowing that people might be busy, on vacations etc.) however they should +not wait weeks until someone looks at their issues. + +Issue Triage team +'''''''''''''''''' + +While many of the issues can be responded to by other users and committers, the committer team is not +big enough to handle all such requests and sometimes they are busy with implementing important huge features +that require focusing for extended periods of time on them, therefore we are inviting people who are +regularly contributing and helping other users and shown their deep interest in the project to the +triage team. The current list of triage team is in `the .asf.yaml <.asf.yaml>`_ file in the +``collaborators`` section. + + +The triage team members do not have committer privileges but they can +assign, edit, and close issues and pull requests without having capabilities to merge the code. They can +also convert issues into discussions and back. The expectation for the issue triage team is that they +spend a bit of their time on those efforts. Triaging means not only assigning the labels but often responding +to the issues and answering user concerns or if additional input is needed - tagging the committers that +and other team members who might help to provide more complete answers. + +Taking active and helpful part of the Issue Triage team is actually one of the paths towards Review Comment: ```suggestion Being an active and helpful member of the Issue Triage team is actually one of the paths towards ``` ########## ISSUE_TRIAGE_PROCESS.rst: ########## @@ -30,6 +30,53 @@ 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. +Another important part of our Issue reporting process are also Github Discussions. +Issues should represent clear feature requests which can/should be implemented. +Users are encouraged to open Discussions rather than Issues if there are no clear, reproducible +steps, or when they have troubleshooting problems. + +Responding to issues/discussions (relatively) quickly +''''''''''''''''''''''''''''''''''''''''''''''''''''' + +It is vital to provide rather quick feedback to Issues and Discussions opened by our users, so that they +feel listened to rather than ignored. Even if the response is "we are not going to work on it because ...", +or "converting this issue to discussion because ..." or "closing because it is a duplicate of #xxx", it is +far more welcoming than leaving issues and discussions unanswered. Sometimes issues and discussions are +answered by other users (and this is cool) but if an issue/discussion is not responded to for few days or +weeks, this gives an impression, that the user reporting it is ignored, that creates an impression of +non-welcoming project. Review Comment: ```suggestion weeks, this gives an impression that the user reporting it is ignored, which creates an impression of a non-welcoming project. ``` ########## ISSUE_TRIAGE_PROCESS.rst: ########## @@ -30,6 +30,53 @@ 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. +Another important part of our Issue reporting process are also Github Discussions. +Issues should represent clear feature requests which can/should be implemented. +Users are encouraged to open Discussions rather than Issues if there are no clear, reproducible +steps, or when they have troubleshooting problems. + +Responding to issues/discussions (relatively) quickly +''''''''''''''''''''''''''''''''''''''''''''''''''''' + +It is vital to provide rather quick feedback to Issues and Discussions opened by our users, so that they +feel listened to rather than ignored. Even if the response is "we are not going to work on it because ...", +or "converting this issue to discussion because ..." or "closing because it is a duplicate of #xxx", it is +far more welcoming than leaving issues and discussions unanswered. Sometimes issues and discussions are +answered by other users (and this is cool) but if an issue/discussion is not responded to for few days or +weeks, this gives an impression, that the user reporting it is ignored, that creates an impression of +non-welcoming project. + +We strive to provide relatively quick responses to all such issues and discussions. Users should exercise +patience while waiting for those (knowing that people might be busy, on vacations etc.) however they should +not wait weeks until someone looks at their issues. + +Issue Triage team +'''''''''''''''''' + +While many of the issues can be responded to by other users and committers, the committer team is not +big enough to handle all such requests and sometimes they are busy with implementing important huge features +that require focusing for extended periods of time on them, therefore we are inviting people who are +regularly contributing and helping other users and shown their deep interest in the project to the +triage team. The current list of triage team is in `the .asf.yaml <.asf.yaml>`_ file in the Review Comment: ```suggestion triage team. The current list of triage team members is in `the .asf.yaml <.asf.yaml>`_ file in the ``` ########## ISSUE_TRIAGE_PROCESS.rst: ########## @@ -30,6 +30,53 @@ 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. +Another important part of our Issue reporting process are also Github Discussions. +Issues should represent clear feature requests which can/should be implemented. Review Comment: ```suggestion Issues should represent clear feature requests or bugs which can/should be either implemented or fixed. ``` ########## ISSUE_TRIAGE_PROCESS.rst: ########## @@ -30,6 +30,53 @@ 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. +Another important part of our Issue reporting process are also Github Discussions. +Issues should represent clear feature requests which can/should be implemented. +Users are encouraged to open Discussions rather than Issues if there are no clear, reproducible +steps, or when they have troubleshooting problems. + +Responding to issues/discussions (relatively) quickly +''''''''''''''''''''''''''''''''''''''''''''''''''''' + +It is vital to provide rather quick feedback to Issues and Discussions opened by our users, so that they +feel listened to rather than ignored. Even if the response is "we are not going to work on it because ...", +or "converting this issue to discussion because ..." or "closing because it is a duplicate of #xxx", it is +far more welcoming than leaving issues and discussions unanswered. Sometimes issues and discussions are +answered by other users (and this is cool) but if an issue/discussion is not responded to for few days or +weeks, this gives an impression, that the user reporting it is ignored, that creates an impression of +non-welcoming project. + +We strive to provide relatively quick responses to all such issues and discussions. Users should exercise +patience while waiting for those (knowing that people might be busy, on vacations etc.) however they should +not wait weeks until someone looks at their issues. + +Issue Triage team +'''''''''''''''''' + +While many of the issues can be responded to by other users and committers, the committer team is not +big enough to handle all such requests and sometimes they are busy with implementing important huge features +that require focusing for extended periods of time on them, therefore we are inviting people who are +regularly contributing and helping other users and shown their deep interest in the project to the +triage team. The current list of triage team is in `the .asf.yaml <.asf.yaml>`_ file in the +``collaborators`` section. + + +The triage team members do not have committer privileges but they can +assign, edit, and close issues and pull requests without having capabilities to merge the code. They can +also convert issues into discussions and back. The expectation for the issue triage team is that they +spend a bit of their time on those efforts. Triaging means not only assigning the labels but often responding +to the issues and answering user concerns or if additional input is needed - tagging the committers that +and other team members who might help to provide more complete answers. + +Taking active and helpful part of the Issue Triage team is actually one of the paths towards +becoming a committer. By actively helping the users and triaging the issues and responding to them and +involving others (when needed) shows that you are not only willing to help our users and the community, +but also give a chance to learn about parts of the project you are not actively contributing to - all of that +are super valuable components of being eligible to `become a committer <COMMITTERS.md>`_. + +If you are a member of the triage team an not able to make any commitment, it's best to ask to get yourself +removed from the triage team. Review Comment: ```suggestion If you are a member of the triage team an not able to make any commitment, it's best to ask to have yourself removed from the triage team. ``` ########## ISSUE_TRIAGE_PROCESS.rst: ########## @@ -30,6 +30,53 @@ 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. +Another important part of our Issue reporting process are also Github Discussions. +Issues should represent clear feature requests which can/should be implemented. +Users are encouraged to open Discussions rather than Issues if there are no clear, reproducible +steps, or when they have troubleshooting problems. + +Responding to issues/discussions (relatively) quickly +''''''''''''''''''''''''''''''''''''''''''''''''''''' + +It is vital to provide rather quick feedback to Issues and Discussions opened by our users, so that they +feel listened to rather than ignored. Even if the response is "we are not going to work on it because ...", +or "converting this issue to discussion because ..." or "closing because it is a duplicate of #xxx", it is +far more welcoming than leaving issues and discussions unanswered. Sometimes issues and discussions are +answered by other users (and this is cool) but if an issue/discussion is not responded to for few days or +weeks, this gives an impression, that the user reporting it is ignored, that creates an impression of +non-welcoming project. + +We strive to provide relatively quick responses to all such issues and discussions. Users should exercise +patience while waiting for those (knowing that people might be busy, on vacations etc.) however they should +not wait weeks until someone looks at their issues. + +Issue Triage team +'''''''''''''''''' + +While many of the issues can be responded to by other users and committers, the committer team is not +big enough to handle all such requests and sometimes they are busy with implementing important huge features +that require focusing for extended periods of time on them, therefore we are inviting people who are +regularly contributing and helping other users and shown their deep interest in the project to the +triage team. The current list of triage team is in `the .asf.yaml <.asf.yaml>`_ file in the +``collaborators`` section. + + +The triage team members do not have committer privileges but they can +assign, edit, and close issues and pull requests without having capabilities to merge the code. They can +also convert issues into discussions and back. The expectation for the issue triage team is that they +spend a bit of their time on those efforts. Triaging means not only assigning the labels but often responding +to the issues and answering user concerns or if additional input is needed - tagging the committers that +and other team members who might help to provide more complete answers. Review Comment: ```suggestion to the issues and answering user concerns or if additional input is needed - tagging the committers or other community members who might be able to help provide more complete answers. ``` ########## ISSUE_TRIAGE_PROCESS.rst: ########## @@ -30,6 +30,53 @@ 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. +Another important part of our Issue reporting process are also Github Discussions. +Issues should represent clear feature requests which can/should be implemented. +Users are encouraged to open Discussions rather than Issues if there are no clear, reproducible +steps, or when they have troubleshooting problems. + +Responding to issues/discussions (relatively) quickly +''''''''''''''''''''''''''''''''''''''''''''''''''''' + +It is vital to provide rather quick feedback to Issues and Discussions opened by our users, so that they +feel listened to rather than ignored. Even if the response is "we are not going to work on it because ...", +or "converting this issue to discussion because ..." or "closing because it is a duplicate of #xxx", it is +far more welcoming than leaving issues and discussions unanswered. Sometimes issues and discussions are +answered by other users (and this is cool) but if an issue/discussion is not responded to for few days or +weeks, this gives an impression, that the user reporting it is ignored, that creates an impression of +non-welcoming project. + +We strive to provide relatively quick responses to all such issues and discussions. Users should exercise +patience while waiting for those (knowing that people might be busy, on vacations etc.) however they should +not wait weeks until someone looks at their issues. + +Issue Triage team +'''''''''''''''''' + +While many of the issues can be responded to by other users and committers, the committer team is not +big enough to handle all such requests and sometimes they are busy with implementing important huge features +that require focusing for extended periods of time on them, therefore we are inviting people who are Review Comment: ```suggestion While many of the issues can be responded to by other users and committers, the committer team is not big enough to handle all such requests and sometimes they are busy with implementing important huge features that require focusing for extended periods of time on them. Therefore, we are inviting people who are ``` -- 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]
