[GitHub] [airflow] shubham22 commented on a diff in pull request #27262: Strenghten a bit and clarify importance of triaging issues

[GitBox <gi...@apache.org>]

shubham22 commented on code in PR #27262:
URL: https://github.com/apache/airflow/pull/27262#discussion_r1007459660


##########
ISSUE_TRIAGE_PROCESS.rst:
##########
@@ -30,6 +30,52 @@ 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.

Review Comment:
   - remove "also"
   - "GitHub",  also may be add a link to it as this is the first time it is mentioned (https://github.com/apache/airflow/discussions)



##########
COMMITTERS.rst:
##########
@@ -75,7 +75,8 @@ Code contribution
 Community contributions
 ^^^^^^^^^^^^^^^^^^^^^^^^
 
-1.  Was instrumental in triaging issues
+1.  Actively participated in `triaging issues <ISSUE_TRIAGE_PROCESS.rst>`_ showing their understanding

Review Comment:
   Points 3~5 are present tense.
   Suggestion: Actively participates in...



##########
ISSUE_TRIAGE_PROCESS.rst:
##########
@@ -30,6 +30,52 @@ 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 or bugs which can/should be either implemented or fixed.
+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 a few days or
+weeks, this gives an impression that the user reporting it is ignored, which creates an impression of a
+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

Review Comment:
   Suggestion: with implementing important and complex features...



##########
ISSUE_TRIAGE_PROCESS.rst:
##########
@@ -30,6 +30,52 @@ 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 or bugs which can/should be either implemented or fixed.
+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 a few days or
+weeks, this gives an impression that the user reporting it is ignored, which creates an impression of a
+non-welcoming project.

Review Comment:
   Suggestion: it gives an impression that the user was ignored and that the Airflow project is unwelcoming.



##########
ISSUE_TRIAGE_PROCESS.rst:
##########
@@ -30,6 +30,52 @@ 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 or bugs which can/should be either implemented or fixed.
+Users are encouraged to open Discussions rather than Issues if there are no clear, reproducible
+steps, or when they have troubleshooting problems.

Review Comment:
   Loved the clear distinction.



##########
ISSUE_TRIAGE_PROCESS.rst:
##########
@@ -30,6 +30,52 @@ 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 or bugs which can/should be either implemented or fixed.
+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

Review Comment:
   out of curiosity, does Airflow have a concept of "this issue needs more research, and we will add this to our backlog for now"?



##########
ISSUE_TRIAGE_PROCESS.rst:
##########
@@ -30,6 +30,52 @@ 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 or bugs which can/should be either implemented or fixed.
+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

Review Comment:
   nit: case for "issues" and "discussions" is sometimes capital and sometime lower



##########
ISSUE_TRIAGE_PROCESS.rst:
##########
@@ -30,6 +30,52 @@ 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 or bugs which can/should be either implemented or fixed.
+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 a few days or
+weeks, this gives an impression that the user reporting it is ignored, which creates an impression of a
+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 members is in  `the .asf.yaml <.asf.yaml>`_ file in the
+``collaborators`` section.

Review Comment:
   After reading this, it is not clear to me if addition to the triage team is voluntary or based on invitations sent out by PMCs (like for becoming a Committer). Can a user who has been actively contributing and responding to users on slack/mailing lists volunteer to be added by herself/himself? 



##########
ISSUE_TRIAGE_PROCESS.rst:
##########
@@ -30,6 +30,52 @@ 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 or bugs which can/should be either implemented or fixed.
+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 a few days or
+weeks, this gives an impression that the user reporting it is ignored, which creates an impression of a
+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 members 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 or other community members who might be able to help provide more complete answers.
+
+Being an active and helpful member 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

Review Comment:
   Suggestion: but are also ready to learn about parts of the projects...



-- 
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: commits-unsubscribe@airflow.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org