You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@airflow.apache.org by GitBox <gi...@apache.org> on 2022/10/25 13:37:30 UTC
[GitHub] [airflow] potiuk opened a new pull request, #27262: Strenghten a bit and clarify importance of triaging issues
potiuk opened a new pull request, #27262:
URL: https://github.com/apache/airflow/pull/27262
Triaging issues is an important part of the work we do. It is crucial that we respond swiftly and accurately to issues and discussions created by our users so that they feel welcome and listened to.
By participation in triaging process, contributors might show not only their willingness of helping other community members, but also show that they understand various parts of airflow (also that they are capable of learning it while helping others - which is one of the best ways to learn parts of Airflow you do not actively contribute to.
<!--
Thank you for contributing! Please make sure that your code changes
are covered with tests. And in case of new features or big changes
remember to adjust the documentation.
Feel free to ping committers for the review!
In case of an existing issue, reference it using one of the following:
closes: #ISSUE
related: #ISSUE
How to write a good git commit message:
http://chris.beams.io/posts/git-commit/
-->
---
**^ Add meaningful description above**
Read the **[Pull Request Guidelines](https://github.com/apache/airflow/blob/main/CONTRIBUTING.rst#pull-request-guidelines)** for more information.
In case of fundamental code changes, an Airflow Improvement Proposal ([AIP](https://cwiki.apache.org/confluence/display/AIRFLOW/Airflow+Improvement+Proposals)) is needed.
In case of a new dependency, check compliance with the [ASF 3rd Party License Policy](https://www.apache.org/legal/resolved.html#category-x).
In case of backwards incompatible changes please leave a note in a newsfragment file, named `{pr_number}.significant.rst` or `{issue_number}.significant.rst`, in [newsfragments](https://github.com/apache/airflow/tree/main/newsfragments).
--
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
[GitHub] [airflow] pierrejeambrun commented on a diff in pull request #27262: Strenghten a bit and clarify importance of triaging issues
Posted by GitBox <gi...@apache.org>.
pierrejeambrun commented on code in PR #27262:
URL: https://github.com/apache/airflow/pull/27262#discussion_r1007709396
##########
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
+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 have yourself
Review Comment:
typo: “**and** not able to”
--
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
[GitHub] [airflow] o-nikolas commented on a diff in pull request #27262: Strenghten a bit and clarify importance of triaging issues
Posted by GitBox <gi...@apache.org>.
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: commits-unsubscribe@airflow.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [airflow] potiuk commented on a diff in pull request #27262: Strenghten a bit and clarify importance of triaging issues
Posted by GitBox <gi...@apache.org>.
potiuk commented on code in PR #27262:
URL: https://github.com/apache/airflow/pull/27262#discussion_r1008754742
##########
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:
Cool!
--
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
[GitHub] [airflow] potiuk commented on pull request #27262: Strenghten a bit and clarify importance of triaging issues
Posted by GitBox <gi...@apache.org>.
potiuk commented on PR #27262:
URL: https://github.com/apache/airflow/pull/27262#issuecomment-1294202399
Any more comments?
--
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
[GitHub] [airflow] potiuk commented on a diff in pull request #27262: Strenghten a bit and clarify importance of triaging issues
Posted by GitBox <gi...@apache.org>.
potiuk commented on code in PR #27262:
URL: https://github.com/apache/airflow/pull/27262#discussion_r1008687543
##########
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:
Yeah. Good point. I clarified that this can be both - by invitation and users can ask for it - but I also added point that (and this is very consistent with our committer's, PMC requirements - you have to do something that is "expected" at a given "level" before you are "formally" invited. As everything in ASF - this is based on merit. You need to show that you are already doing something (i.e. almost committer's or PMC's "things") before you are invited to be committer/PMC - same as triager. You need to comment and help users regularly before you become a member of triage team. In Airflow (and all other ASF project) we do not give priviledges to people based on "promises" that they will do something but on the base on them "already doing something".
That's how merit is defined as an important part of the Apache Way: https://www.apache.org/theapacheway/ - "Earned authority" or "merit". If you are asking to become a member of the triage team, you need to show you have done a lot of that already (pretty much everything except assigning labels/milestones/closing issues can be done by regular users - commenting, mentioning others, assessing validity of the issues can be done by everyone.
--
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
[GitHub] [airflow] potiuk commented on pull request #27262: Strenghten a bit and clarify importance of triaging issues
Posted by GitBox <gi...@apache.org>.
potiuk commented on PR #27262:
URL: https://github.com/apache/airflow/pull/27262#issuecomment-1304836523
Merging as is. We can always improve it later.
--
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
[GitHub] [airflow] potiuk commented on a diff in pull request #27262: Strenghten a bit and clarify importance of triaging issues
Posted by GitBox <gi...@apache.org>.
potiuk commented on code in PR #27262:
URL: https://github.com/apache/airflow/pull/27262#discussion_r1008683240
##########
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:
Not directly. We do not have anyone looking at the backlog and we will not have likely. We smply leave issues open - if we have not enough information, we ask for it in the issue and that's basically it. Since all issues are open and visible to anyone (and searchable) if other people will see it, they might add extra information that might lead us to further investigations.
However we have something "like" that. If we think that issue is important but we have no clue we often add it to "next bugfix milestone". Which is an indication that we at least should look at it before the next release and we can decide during release preparation what we should do with it.
That's cool you mentioned it - this was something done implicitly without actually writing it down. I will add it here.
--
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
[GitHub] [airflow] potiuk commented on a diff in pull request #27262: Strenghten a bit and clarify importance of triaging issues
Posted by GitBox <gi...@apache.org>.
potiuk commented on code in PR #27262:
URL: https://github.com/apache/airflow/pull/27262#discussion_r1008682712
##########
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:
Right :)
--
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
[GitHub] [airflow] potiuk commented on a diff in pull request #27262: Strenghten a bit and clarify importance of triaging issues
Posted by GitBox <gi...@apache.org>.
potiuk commented on code in PR #27262:
URL: https://github.com/apache/airflow/pull/27262#discussion_r1008716321
##########
ISSUE_TRIAGE_PROCESS.rst:
##########
@@ -27,16 +24,116 @@ of resolving issues.
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.
+This is intended to make it as easy as possible to contribute to the project.
+
+Usually users are report `Issues <https://github.com/apache/airflow/issues>`_ where they describe
+the issues they think are Airflow issues and should be solved. There are two kinds of issues:
+
+* Bugs - when the user thinks the reported issue is a bug in Airflow
+* Features - when there are small features that the user would like to see in Airflow
+
+We have `templates <https://github.com/apache/airflow/tree/main/.github/ISSUE_TEMPLATE>`_ for both types
+of issues defined in Airflow.
+
+However, important part of our issue reporting process are
+`GitHub Discussions <https://github.com/apache/airflow/discussions>`_ . Issues should represent
+clear, small feature requests or reproducible 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, and one of the important points of issue triaging is
+to determine if the issue reported should be rather a discussion. Converting an issue to a discussion
+while explaining the user why is an important part of triaging process.
+
+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 was ignored and that the Airflow project is unwelcoming.
+
+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
+and complex features that require focusing for extended periods of time on them. Therefore, some 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 can be found in
+`the .asf.yaml <.asf.yaml>`_ file in the ``collaborators`` section.
+
+Committers can invite people to become members of the triage team if they see that the users are already
+helping and responding to issues and when they see the users are involved regularly. But you can also ask
+to become a member of the team (on devlist) if you can show that you have done that and when you want to have
+more ways to help others.
+
+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 are also ready to learn about parts of the projects 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 and not able to make any commitment, it's best to ask to have yourself
+removed from the triage team.
+
+BTW. Every committer is pretty much automatically part of the "Issue Triage Team" - so if you are committer,
+feel free to follow the process for every issue you stumble upon.
+
+Actions that can be taken by the issue triager
+''''''''''''''''''''''''''''''''''''''''''''''
+
+There are several actions an issue triager might take:
+
+* Closing and issue with "invalid" label explaining why it is closed in case the issue is invalid. This
+ should be accompanied by information that we cn always re-open an issue if our understanding was wrong
+ or if the user provides more information.
+
+* Converting an issue to a discussion, if it is not very likely it is an Airflow issue or when it is not
+ responsible, or when it is a bigger feature proposal requiring discussion or when it's really users
+ troubleshooting or when the issue description is not at all clear. This also involves inviting the user
+ to a discussion if more information might change it.
+
+* If the issue seems important enough that it should likely be looked at before the next release but there
Review Comment:
very good point :). Consistency above all :)
--
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
[GitHub] [airflow] potiuk commented on pull request #27262: Strenghten a bit and clarify importance of triaging issues
Posted by GitBox <gi...@apache.org>.
potiuk commented on PR #27262:
URL: https://github.com/apache/airflow/pull/27262#issuecomment-1295869249
Applied all comments from @pierrejeambrun @shubham22 as well and rebased. Let's see if others will chime in after pinging in the devlist.
--
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
[GitHub] [airflow] potiuk commented on a diff in pull request #27262: Strenghten a bit and clarify importance of triaging issues
Posted by GitBox <gi...@apache.org>.
potiuk commented on code in PR #27262:
URL: https://github.com/apache/airflow/pull/27262#discussion_r1008677059
##########
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:
Good point. Fixed.
--
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
[GitHub] [airflow] potiuk commented on a diff in pull request #27262: Strenghten a bit and clarify importance of triaging issues
Posted by GitBox <gi...@apache.org>.
potiuk commented on code in PR #27262:
URL: https://github.com/apache/airflow/pull/27262#discussion_r1008682424
##########
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:
Good catch. I reviewed and left only beegining of sentences and "GitHub Issues". "GitHub Discussion", "Issue Triage Team" capitalized (and quoted)
--
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
[GitHub] [airflow] potiuk commented on a diff in pull request #27262: Strenghten a bit and clarify importance of triaging issues
Posted by GitBox <gi...@apache.org>.
potiuk commented on code in PR #27262:
URL: https://github.com/apache/airflow/pull/27262#discussion_r1008685841
##########
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:
yep.
--
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
[GitHub] [airflow] shubham22 commented on a diff in pull request #27262: Strenghten a bit and clarify importance of triaging issues
Posted by 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
[GitHub] [airflow] shubham22 commented on a diff in pull request #27262: Strenghten a bit and clarify importance of triaging issues
Posted by GitBox <gi...@apache.org>.
shubham22 commented on code in PR #27262:
URL: https://github.com/apache/airflow/pull/27262#discussion_r1008752609
##########
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:
This was one of the most important pieces for me in this PR. Appreciate the details and clarity here.
--
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
[GitHub] [airflow] shubham22 commented on a diff in pull request #27262: Strenghten a bit and clarify importance of triaging issues
Posted by GitBox <gi...@apache.org>.
shubham22 commented on code in PR #27262:
URL: https://github.com/apache/airflow/pull/27262#discussion_r1008752251
##########
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:
This was helpful explanation. Yea, I read about "next bugfix milestone" in slack conversation, but didn't see it in the GitHub rst. Thanks for adding it.
--
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
[GitHub] [airflow] potiuk commented on pull request #27262: Strenghten a bit and clarify importance of triaging issues
Posted by GitBox <gi...@apache.org>.
potiuk commented on PR #27262:
URL: https://github.com/apache/airflow/pull/27262#issuecomment-1295965956
I have a feeling that the title of the PR/Commit should be changed after all those comments :)
--
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
[GitHub] [airflow] potiuk commented on a diff in pull request #27262: Strenghten a bit and clarify importance of triaging issues
Posted by GitBox <gi...@apache.org>.
potiuk commented on code in PR #27262:
URL: https://github.com/apache/airflow/pull/27262#discussion_r1008687574
##########
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
+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 have yourself
Review Comment:
Right :)
--
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
[GitHub] [airflow] potiuk commented on a diff in pull request #27262: Strenghten a bit and clarify importance of triaging issues
Posted by GitBox <gi...@apache.org>.
potiuk commented on code in PR #27262:
URL: https://github.com/apache/airflow/pull/27262#discussion_r1008681709
##########
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:
I actually rewrote that part quite a bit, and added a bit more guidance on what Issues are an explaining that converting issues to discussions is an important part of the triaging.
--
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
[GitHub] [airflow] pierrejeambrun commented on a diff in pull request #27262: Strenghten a bit and clarify importance of triaging issues
Posted by GitBox <gi...@apache.org>.
pierrejeambrun commented on code in PR #27262:
URL: https://github.com/apache/airflow/pull/27262#discussion_r1008710636
##########
ISSUE_TRIAGE_PROCESS.rst:
##########
@@ -27,16 +24,116 @@ of resolving issues.
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.
+This is intended to make it as easy as possible to contribute to the project.
+
+Usually users are report `Issues <https://github.com/apache/airflow/issues>`_ where they describe
+the issues they think are Airflow issues and should be solved. There are two kinds of issues:
+
+* Bugs - when the user thinks the reported issue is a bug in Airflow
+* Features - when there are small features that the user would like to see in Airflow
+
+We have `templates <https://github.com/apache/airflow/tree/main/.github/ISSUE_TEMPLATE>`_ for both types
+of issues defined in Airflow.
+
+However, important part of our issue reporting process are
+`GitHub Discussions <https://github.com/apache/airflow/discussions>`_ . Issues should represent
+clear, small feature requests or reproducible 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, and one of the important points of issue triaging is
+to determine if the issue reported should be rather a discussion. Converting an issue to a discussion
+while explaining the user why is an important part of triaging process.
+
+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 was ignored and that the Airflow project is unwelcoming.
+
+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
+and complex features that require focusing for extended periods of time on them. Therefore, some 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 can be found in
+`the .asf.yaml <.asf.yaml>`_ file in the ``collaborators`` section.
+
+Committers can invite people to become members of the triage team if they see that the users are already
+helping and responding to issues and when they see the users are involved regularly. But you can also ask
+to become a member of the team (on devlist) if you can show that you have done that and when you want to have
+more ways to help others.
+
+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 are also ready to learn about parts of the projects 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 and not able to make any commitment, it's best to ask to have yourself
+removed from the triage team.
+
+BTW. Every committer is pretty much automatically part of the "Issue Triage Team" - so if you are committer,
+feel free to follow the process for every issue you stumble upon.
+
+Actions that can be taken by the issue triager
+''''''''''''''''''''''''''''''''''''''''''''''
+
+There are several actions an issue triager might take:
+
+* Closing and issue with "invalid" label explaining why it is closed in case the issue is invalid. This
+ should be accompanied by information that we cn always re-open an issue if our understanding was wrong
Review Comment:
```suggestion
should be accompanied by information that we can always re-open an issue if our understanding was wrong
```
##########
ISSUE_TRIAGE_PROCESS.rst:
##########
@@ -27,16 +24,116 @@ of resolving issues.
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.
+This is intended to make it as easy as possible to contribute to the project.
+
+Usually users are report `Issues <https://github.com/apache/airflow/issues>`_ where they describe
+the issues they think are Airflow issues and should be solved. There are two kinds of issues:
+
+* Bugs - when the user thinks the reported issue is a bug in Airflow
+* Features - when there are small features that the user would like to see in Airflow
+
+We have `templates <https://github.com/apache/airflow/tree/main/.github/ISSUE_TEMPLATE>`_ for both types
+of issues defined in Airflow.
+
+However, important part of our issue reporting process are
+`GitHub Discussions <https://github.com/apache/airflow/discussions>`_ . Issues should represent
+clear, small feature requests or reproducible 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, and one of the important points of issue triaging is
+to determine if the issue reported should be rather a discussion. Converting an issue to a discussion
+while explaining the user why is an important part of triaging process.
+
+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 was ignored and that the Airflow project is unwelcoming.
+
+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
+and complex features that require focusing for extended periods of time on them. Therefore, some 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 can be found in
+`the .asf.yaml <.asf.yaml>`_ file in the ``collaborators`` section.
+
+Committers can invite people to become members of the triage team if they see that the users are already
+helping and responding to issues and when they see the users are involved regularly. But you can also ask
+to become a member of the team (on devlist) if you can show that you have done that and when you want to have
+more ways to help others.
+
+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 are also ready to learn about parts of the projects 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 and not able to make any commitment, it's best to ask to have yourself
+removed from the triage team.
+
+BTW. Every committer is pretty much automatically part of the "Issue Triage Team" - so if you are committer,
+feel free to follow the process for every issue you stumble upon.
+
+Actions that can be taken by the issue triager
+''''''''''''''''''''''''''''''''''''''''''''''
+
+There are several actions an issue triager might take:
+
+* Closing and issue with "invalid" label explaining why it is closed in case the issue is invalid. This
+ should be accompanied by information that we cn always re-open an issue if our understanding was wrong
+ or if the user provides more information.
+
+* Converting an issue to a discussion, if it is not very likely it is an Airflow issue or when it is not
+ responsible, or when it is a bigger feature proposal requiring discussion or when it's really users
+ troubleshooting or when the issue description is not at all clear. This also involves inviting the user
+ to a discussion if more information might change it.
+
+* If the issue seems important enough that it should likely be looked at before the next release but there
Review Comment:
All actions start with a verb, maybe rewording to start with 'Assigning the issue to the milestone....'
##########
ISSUE_TRIAGE_PROCESS.rst:
##########
@@ -27,16 +24,116 @@ of resolving issues.
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.
+This is intended to make it as easy as possible to contribute to the project.
+
+Usually users are report `Issues <https://github.com/apache/airflow/issues>`_ where they describe
+the issues they think are Airflow issues and should be solved. There are two kinds of issues:
+
+* Bugs - when the user thinks the reported issue is a bug in Airflow
+* Features - when there are small features that the user would like to see in Airflow
+
+We have `templates <https://github.com/apache/airflow/tree/main/.github/ISSUE_TEMPLATE>`_ for both types
+of issues defined in Airflow.
+
+However, important part of our issue reporting process are
+`GitHub Discussions <https://github.com/apache/airflow/discussions>`_ . Issues should represent
+clear, small feature requests or reproducible 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, and one of the important points of issue triaging is
+to determine if the issue reported should be rather a discussion. Converting an issue to a discussion
+while explaining the user why is an important part of triaging process.
+
+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 was ignored and that the Airflow project is unwelcoming.
+
+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
+and complex features that require focusing for extended periods of time on them. Therefore, some 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 can be found in
Review Comment:
I feel like we are missing a verb here, not sure I understand the sentence.
```suggestion
Therefore, some people who are regularly contributing and helping other users and shown their deep interest
in the project can be invited to join the triage team.
```
##########
ISSUE_TRIAGE_PROCESS.rst:
##########
@@ -27,16 +24,116 @@ of resolving issues.
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.
+This is intended to make it as easy as possible to contribute to the project.
+
+Usually users are report `Issues <https://github.com/apache/airflow/issues>`_ where they describe
+the issues they think are Airflow issues and should be solved. There are two kinds of issues:
+
+* Bugs - when the user thinks the reported issue is a bug in Airflow
+* Features - when there are small features that the user would like to see in Airflow
+
+We have `templates <https://github.com/apache/airflow/tree/main/.github/ISSUE_TEMPLATE>`_ for both types
+of issues defined in Airflow.
+
+However, important part of our issue reporting process are
+`GitHub Discussions <https://github.com/apache/airflow/discussions>`_ . Issues should represent
+clear, small feature requests or reproducible 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, and one of the important points of issue triaging is
+to determine if the issue reported should be rather a discussion. Converting an issue to a discussion
+while explaining the user why is an important part of triaging process.
+
+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 was ignored and that the Airflow project is unwelcoming.
+
+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
+and complex features that require focusing for extended periods of time on them. Therefore, some 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 can be found in
+`the .asf.yaml <.asf.yaml>`_ file in the ``collaborators`` section.
+
+Committers can invite people to become members of the triage team if they see that the users are already
+helping and responding to issues and when they see the users are involved regularly. But you can also ask
+to become a member of the team (on devlist) if you can show that you have done that and when you want to have
+more ways to help others.
+
+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 are also ready to learn about parts of the projects you are not actively contributing to - all of that
+are super valuable components of being eligible to `become a committer <COMMITTERS.md>`_.
Review Comment:
```suggestion
becoming a committer. By actively helping the users, triaging the issues, responding to them and
involving others (when needed) shows that you are not only willing to help our users and the community,
but are also ready to learn about parts of the projects you are not actively contributing to - all of that
are super valuable components of being eligible to `become a committer <COMMITTERS.md>`_.
```
##########
ISSUE_TRIAGE_PROCESS.rst:
##########
@@ -27,16 +24,116 @@ of resolving issues.
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.
+This is intended to make it as easy as possible to contribute to the project.
+
+Usually users are report `Issues <https://github.com/apache/airflow/issues>`_ where they describe
+the issues they think are Airflow issues and should be solved. There are two kinds of issues:
+
+* Bugs - when the user thinks the reported issue is a bug in Airflow
+* Features - when there are small features that the user would like to see in Airflow
+
+We have `templates <https://github.com/apache/airflow/tree/main/.github/ISSUE_TEMPLATE>`_ for both types
+of issues defined in Airflow.
+
+However, important part of our issue reporting process are
+`GitHub Discussions <https://github.com/apache/airflow/discussions>`_ . Issues should represent
+clear, small feature requests or reproducible 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, and one of the important points of issue triaging is
+to determine if the issue reported should be rather a discussion. Converting an issue to a discussion
+while explaining the user why is an important part of triaging process.
+
+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 was ignored and that the Airflow project is unwelcoming.
+
+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
+and complex features that require focusing for extended periods of time on them. Therefore, some 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 can be found in
+`the .asf.yaml <.asf.yaml>`_ file in the ``collaborators`` section.
+
+Committers can invite people to become members of the triage team if they see that the users are already
+helping and responding to issues and when they see the users are involved regularly. But you can also ask
+to become a member of the team (on devlist) if you can show that you have done that and when you want to have
+more ways to help others.
+
+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 are also ready to learn about parts of the projects 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 and not able to make any commitment, it's best to ask to have yourself
+removed from the triage team.
+
+BTW. Every committer is pretty much automatically part of the "Issue Triage Team" - so if you are committer,
+feel free to follow the process for every issue you stumble upon.
+
+Actions that can be taken by the issue triager
+''''''''''''''''''''''''''''''''''''''''''''''
+
+There are several actions an issue triager might take:
+
+* Closing and issue with "invalid" label explaining why it is closed in case the issue is invalid. This
+ should be accompanied by information that we cn always re-open an issue if our understanding was wrong
+ or if the user provides more information.
+
+* Converting an issue to a discussion, if it is not very likely it is an Airflow issue or when it is not
+ responsible, or when it is a bigger feature proposal requiring discussion or when it's really users
+ troubleshooting or when the issue description is not at all clear. This also involves inviting the user
+ to a discussion if more information might change it.
+
+* If the issue seems important enough that it should likely be looked at before the next release but there
+ is not enough information or doubts on why and what can be fixed, assign the issue to the milestone of
+ the next bugfix - then, no matter what the issue will be looked at by the release manager and it might
+ trigger additional actions during the release preparation. This is usually followed by one of the next
+ actions.
+
+* Actually fixing the issue in a PR if you see it is easy to fix. This is a great way also to learn and
+ contribute to parts that you usually are not contributing to, and sometimes it is surprisingly easy.
+
+* Assign "good first issue" label if an issue is clear but not important to be fixed immediately, This
Review Comment:
```suggestion
* Assigning "good first issue" label if an issue is clear but not important to be fixed immediately, This
```
To be consistant with other actions (asking, fixing, calling, assigning, converting...)
--
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
[GitHub] [airflow] potiuk merged pull request #27262: Strenghten a bit and clarify importance of triaging issues
Posted by GitBox <gi...@apache.org>.
potiuk merged PR #27262:
URL: https://github.com/apache/airflow/pull/27262
--
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