potiuk commented on code in PR #36472:
URL: https://github.com/apache/airflow/pull/36472#discussion_r1437834242
##########
CONTRIBUTING.rst:
##########
@@ -453,6 +453,29 @@ Step 4: Prepare PR
PR guidelines described in `pull request guidelines
<#pull-request-guidelines>`_.
Create Pull Request! Make yourself ready for the discussion!
+5. The ``static checks`` and ``tests`` in your PR serve as a
first-line-of-check, whether the PR
+ passes the quality bar for Airflow. It basically means that until you get
your PR green, it is not
+ likely to get reviewed by committers unless you specifically ask for it and
explain that you would like
+ to get first pass of reviews and explain why achieving ``green`` status for
it is not easy/feasible/desired.
+ Similarly if your PR contains ``[WIP]`` in the title or it is marked as
``Draft`` it is not likely to get
+ reviewed by committers unless you specifically ask for it and explain why
and what specifically you want
+ to get reviewed before it reaches ``Ready for review`` status. This might
happen if you want to get initial
+ feedback on the direction of your PR or if you want to get feedback on the
design of your PR.
+
+6. Avoid @-mentioning individual committers in your PR, unless you have good
reason to believe that they are
+ available, have time and interest in your PR. Generally speaking there are
no "exclusive" reviewers for
+ different parts of the code and reviewers review PRs and respond when they
have some free time to spare and
+ when they feel they can provide valuable feedback. If you want to get
attention of committers, you can just
+ follow-up on your PR and ask for review in general, however be considerate
and do not expect "immediate"
+ reviews. People review when they have time, most of the people who are
committers do such reviews in their
Review Comment:
yeah
##########
CONTRIBUTING.rst:
##########
@@ -453,6 +453,29 @@ Step 4: Prepare PR
PR guidelines described in `pull request guidelines
<#pull-request-guidelines>`_.
Create Pull Request! Make yourself ready for the discussion!
+5. The ``static checks`` and ``tests`` in your PR serve as a
first-line-of-check, whether the PR
+ passes the quality bar for Airflow. It basically means that until you get
your PR green, it is not
+ likely to get reviewed by committers unless you specifically ask for it and
explain that you would like
+ to get first pass of reviews and explain why achieving ``green`` status for
it is not easy/feasible/desired.
+ Similarly if your PR contains ``[WIP]`` in the title or it is marked as
``Draft`` it is not likely to get
+ reviewed by committers unless you specifically ask for it and explain why
and what specifically you want
+ to get reviewed before it reaches ``Ready for review`` status. This might
happen if you want to get initial
+ feedback on the direction of your PR or if you want to get feedback on the
design of your PR.
+
+6. Avoid @-mentioning individual committers in your PR, unless you have good
reason to believe that they are
+ available, have time and interest in your PR. Generally speaking there are
no "exclusive" reviewers for
+ different parts of the code and reviewers review PRs and respond when they
have some free time to spare and
+ when they feel they can provide valuable feedback. If you want to get
attention of committers, you can just
+ follow-up on your PR and ask for review in general, however be considerate
and do not expect "immediate"
+ reviews. People review when they have time, most of the people who are
committers do such reviews in their
+ free time, which is taken away from their families and other interests so
allow sufficient time before you
+ follow-up - but If you see no reaction in several days, do follow-up, as
with the number of PRs we have
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: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
