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 2020/01/18 13:30:27 UTC

[GitHub] [airflow] potiuk opened a new pull request #7204: [AIRFLOW-XXXX] - add communication chapter to contributing

potiuk opened a new pull request #7204: [AIRFLOW-XXXX] - add communication chapter to contributing
URL: https://github.com/apache/airflow/pull/7204
 
 
   ---
   Issue link: WILL BE INSERTED BY [boring-cyborg](https://github.com/kaxil/boring-cyborg)
   
   Make sure to mark the boxes below before creating PR: [x]
   
   - [x] Description above provides context of the change
   - [x] Commit message/PR title starts with `[AIRFLOW-NNNN]`. AIRFLOW-NNNN = JIRA ID<sup>*</sup>
   - [x] Unit tests coverage for changes (not needed for documentation changes)
   - [x] Commits follow "[How to write a good git commit message](http://chris.beams.io/posts/git-commit/)"
   - [x] Relevant documentation is updated including usage instructions.
   - [x] I will engage committers as explained in [Contribution Workflow Example](https://github.com/apache/airflow/blob/master/CONTRIBUTING.rst#contribution-workflow-example).
   
   <sup>*</sup> For document-only changes commit message can start with `[AIRFLOW-XXXX]`.
   
   ---
   In case of fundamental code change, Airflow Improvement Proposal ([AIP](https://cwiki.apache.org/confluence/display/AIRFLOW/Airflow+Improvements+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 [UPDATING.md](https://github.com/apache/airflow/blob/master/UPDATING.md).
   Read the [Pull Request Guidelines](https://github.com/apache/airflow/blob/master/CONTRIBUTING.rst#pull-request-guidelines) for more information.
   

----------------------------------------------------------------
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.
 
For queries about this service, please contact Infrastructure at:
users@infra.apache.org


With regards,
Apache Git Services

[GitHub] [airflow] nuclearpinguin commented on a change in pull request #7204: [AIRFLOW-XXXX] - add communication chapter to contributing

Posted by GitBox <gi...@apache.org>.
nuclearpinguin commented on a change in pull request #7204: [AIRFLOW-XXXX] - add communication chapter to contributing
URL: https://github.com/apache/airflow/pull/7204#discussion_r368311030
 
 

 ##########
 File path: CONTRIBUTING.rst
 ##########
 @@ -664,6 +664,63 @@ Later on
    above depending if you have more commits that cause conflicts in your PR (rebasing applies each
    commit from your PR one-by-one).
 
+How to communicate
+==================
+
+Apache Airflow is a Community within Apache Software Foundation. As the motto of
+the Apache Software Foundation states "Community over Code" - people in the
+community are far more important than the code they create.
+
+This means that communication is very important, and this chapter is all about it.
+
+We have various channel of communication - starting from the official devlist, comments
+in the Pull Requests, Slack, wiki.
+
+All those channels can be used for different purposes:
+
+* The devlist for official communication, discussing proposals, voting, general issues, asking community for
+  opinion etc.
+* Wiki for detailed discussions on big proposals (AIPs) and some helpful, shared resources.
+* PRs for discussing implementation details of this PR (not for architectural discussions)
+* Slack for ad-hoc questions, troubleshooting, occassional discussions, group talks (including SIG - special
+interest groups), notifications, random queries, newbie questions etc.
+
+
+It is important to remember that all contributors, committers and even PMC members are individuals
+that contribute a lot of their free time on top of their work time to Apache Airflow.
 
 Review comment:
   ```suggestion
   that contribute a lot of their free time on top of their work time to develop Apache Airflow.
   ```

----------------------------------------------------------------
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.
 
For queries about this service, please contact Infrastructure at:
users@infra.apache.org


With regards,
Apache Git Services

[GitHub] [airflow] potiuk commented on a change in pull request #7204: [AIRFLOW-XXXX] - add communication chapter to contributing

Posted by GitBox <gi...@apache.org>.
potiuk commented on a change in pull request #7204: [AIRFLOW-XXXX] - add communication chapter to contributing
URL: https://github.com/apache/airflow/pull/7204#discussion_r380397786
 
 

 ##########
 File path: CONTRIBUTING.rst
 ##########
 @@ -664,6 +664,73 @@ Later on
    above depending if you have more commits that cause conflicts in your PR (rebasing applies each
    commit from your PR one-by-one).
 
+How to communicate
+==================
+
+Apache Airflow is a Community within Apache Software Foundation. As the motto of
+the Apache Software Foundation states "Community over Code" - people in the
+community are far more important than their contribution.
+
+This means that communication is very important, and this chapter is all about it.
+
+We have various channel of communication - starting from the official devlist, comments
+in the Pull Requests, Slack, wiki.
+
+All those channels can be used for different purposes:
+
+* The devlist for official communication, discussing proposals, voting, general issues, asking community for
+  opinion etc.
+* Wiki for detailed discussions on big proposals (AIPs) and some helpful, shared resources.
+* PRs for discussing implementation details of this PR (not for architectural discussions)
+* Slack for ad-hoc questions, troubleshooting, occassional discussions, group talks (including SIG - special
+interest groups), notifications, random queries, newbie questions etc.
+
+
+It is important to remember that all contributors, committers and even PMC members are individuals
+that contribute a lot of their free time on top of their work time to develop Apache Airflow.
+They have families, personal life, sometimes they are swamped with work, sometimes they are on vacations
+sometimes they are simply tired and need a time off. They are in various timezones and their responsiveness
+will vary from time to time. As a community project we have no formal structure, we have no managers nor
+departments and most of the people are autonomous in their opinions and decisions, so sometimes even
+committers will have different opinions on the same subjects.
+
+Disagreements are expected, discussions might include strong opinions and contradicting statements.
+Sometimes you might get two committers asking you to do things differently. This all happened in the past
+and will continue to happen. As a community we have some mechanisms to facilitate discussion and come to
+a consensus, conclusions and sometime we end up voting certain decisions. It is important that those
+decisions are not treated as personal wins or looses. At the end it's the community that we all care about
+and what's good for community, should be accepted even if you have different opinion. There is the nice
+motto that you should follow in case you disagree with community decision "Disagree but engage". Even
+if you do not agree with a community decision, you should follow it and embrace (but you are free to
+express your opinion that you don't agree with it).
+
+As a community - we have high requirements for code quality. This is mainly because we are a distributed
+and loosely organised team - sometime we have contributors that commit one commit only, sometimes people add
+more commits, sometimes people assume informal "stewardship" over parts of code for some time - but at any
+time we should be sure that the code can be taken over by others - without excessive communication. Setting
+high requirements for the code (fairly strict code review, static code checks, requirements of automated
+tests, pre-commit checks ) is the best way that we can achieve that - by only accepting good quality
+code with full test coverage we make sure that we can work with the code in the future.
+So do not be surprised if you are asked to add more tests or make the code cleaner -
+this is for the sake of maintainability.
+
+Here are a few rules that are important to keep in mind when you enter our community:
+
+ * Do not be afraid to ask questions
+ * The communication is asynchronous - do not expect immediate answers, ping others if you are blocked
+ * There is a #newbie-questions channel in slack as a safe place to ask questions
 
 Review comment:
   Done

----------------------------------------------------------------
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.
 
For queries about this service, please contact Infrastructure at:
users@infra.apache.org


With regards,
Apache Git Services

[GitHub] [airflow] mschickensoup commented on a change in pull request #7204: [AIRFLOW-XXXX] - add communication chapter to contributing

Posted by GitBox <gi...@apache.org>.
mschickensoup commented on a change in pull request #7204: [AIRFLOW-XXXX] - add communication chapter to contributing
URL: https://github.com/apache/airflow/pull/7204#discussion_r369639040
 
 

 ##########
 File path: CONTRIBUTING.rst
 ##########
 @@ -664,6 +664,73 @@ Later on
    above depending if you have more commits that cause conflicts in your PR (rebasing applies each
    commit from your PR one-by-one).
 
+How to communicate
+==================
+
+Apache Airflow is a Community within Apache Software Foundation. As the motto of
+the Apache Software Foundation states "Community over Code" - people in the
+community are far more important than their contribution.
+
+This means that communication is very important, and this chapter is all about it.
+
+We have various channel of communication - starting from the official devlist, comments
+in the Pull Requests, Slack, wiki.
+
+All those channels can be used for different purposes:
+
+* The devlist for official communication, discussing proposals, voting, general issues, asking community for
+  opinion etc.
+* Wiki for detailed discussions on big proposals (AIPs) and some helpful, shared resources.
+* PRs for discussing implementation details of this PR (not for architectural discussions)
+* Slack for ad-hoc questions, troubleshooting, occassional discussions, group talks (including SIG - special
+interest groups), notifications, random queries, newbie questions etc.
+
+
+It is important to remember that all contributors, committers and even PMC members are individuals
+that contribute a lot of their free time on top of their work time to develop Apache Airflow.
+They have families, personal life, sometimes they are swamped with work, sometimes they are on vacations
+sometimes they are simply tired and need a time off. They are in various timezones and their responsiveness
+will vary from time to time. As a community project we have no formal structure, we have no managers nor
+departments and most of the people are autonomous in their opinions and decisions, so sometimes even
+committers will have different opinions on the same subjects.
+
+Disagreements are expected, discussions might include strong opinions and contradicting statements.
+Sometimes you might get two committers asking you to do things differently. This all happened in the past
+and will continue to happen. As a community we have some mechanisms to facilitate discussion and come to
+a consensus, conclusions and sometime we end up voting certain decisions. It is important that those
+decisions are not treated as personal wins or looses. At the end it's the community that we all care about
+and what's good for community, should be accepted even if you have different opinion. There is the nice
+motto that you should follow in case you disagree with community decision "Disagree but engage". Even
+if you do not agree with a community decision, you should follow it and embrace (but you are free to
+express your opinion that you don't agree with it).
+
+As a community - we have high requirements for code quality. This is mainly because we are a distributed
+and loosely organised team - sometime we have contributors that commit one commit only, sometimes people add
+more commits, sometimes people assume informal "stewardship" over parts of code for some time - but at any
+time we should be sure that the code can be taken over by others - without excessive communication. Setting
+high requirements for the code (fairly strict code review, static code checks, requirements of automated
+tests, pre-commit checks ) is the best way that we can achieve that - by only accepting good quality
+code with full test coverage we make sure that we can work with the code in the future.
 
 Review comment:
   ```suggestion
   code. Thanks to full test coverage we can make sure that we will be able to work with the code in the future.
   ```

----------------------------------------------------------------
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.
 
For queries about this service, please contact Infrastructure at:
users@infra.apache.org


With regards,
Apache Git Services

[GitHub] [airflow] potiuk merged pull request #7204: [AIRFLOW-XXXX] - add communication chapter to contributing

Posted by GitBox <gi...@apache.org>.
potiuk merged pull request #7204: [AIRFLOW-XXXX] - add communication chapter to contributing
URL: https://github.com/apache/airflow/pull/7204
 
 
   

----------------------------------------------------------------
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.
 
For queries about this service, please contact Infrastructure at:
users@infra.apache.org


With regards,
Apache Git Services

[GitHub] [airflow] tooptoop4 commented on a change in pull request #7204: [AIRFLOW-XXXX] - add communication chapter to contributing

Posted by GitBox <gi...@apache.org>.
tooptoop4 commented on a change in pull request #7204: [AIRFLOW-XXXX] - add communication chapter to contributing
URL: https://github.com/apache/airflow/pull/7204#discussion_r368236353
 
 

 ##########
 File path: CONTRIBUTING.rst
 ##########
 @@ -567,6 +567,63 @@ Step 5: Pass PR Review
 Note that committers will use **Squash and Merge** instead of **Rebase and Merge**
 when merging PRs and your commit will be squashed to single commit.
 
+Communication
+=============
+
+Apache Airflow is a Community within Apache Software Foundation. As the motto of
+the Apache Software Foundation states "Community over Code" - people in the
+community are far more important than the code they create.
+
+This means that communication is very important, and this chapter is all about it.
+
+We have various channel of communication - starting from the official devlist, comments
+in the Pull Requests, Slack, wiki.
+
+All those channels can be used for different purposes:
+
+* The devlist for official communication, discussing proposals, voting, general issues, asking community for
+  opinion etc.
+* Wiki for detailed discussions on big proposals (AIPs) and some helpful, shared resources.
+* PRs for discussing implementation details of this PR (not for architectural discussions)
+* Slack for ad-hoc questions, troubleshooting, occassional discussions, group talks (including SIG - special
+interest groups), notifications, random queries, newbie questions etc.
+
+
+It is important to remember that all contributors, committers and even PMC members are individuals
+that contribute a lot of their free time on top of their work time to Apache Airflow.
+They have families, personal life, sometimes they are swamped with work, sometimes they are on vacations
+sometimes they are simply tired and need a time off. They are in various timezones and their responsiveness
+will vary from time to time. As a community project we have no formal structure, we have no managers nor
+departments and most of the people are autonomous in their opinions and decisions, so sometimes even
+committers will have different opinions on the same subjects.
+
+Disagreements are expected, discussions might include strong opinions and contradicting statements.
+Sometimes you might get two committers asking you to do things differently. This all happened in the past
+and will continue to happen. As a community we have some mechanisms to facilitate discussion and come to
+a consesus, conclusions and sometime we end up voting certain decisions. It is important that those
 
 Review comment:
   consesus typo

----------------------------------------------------------------
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.
 
For queries about this service, please contact Infrastructure at:
users@infra.apache.org


With regards,
Apache Git Services

[GitHub] [airflow] nuclearpinguin commented on a change in pull request #7204: [AIRFLOW-XXXX] - add communication chapter to contributing

Posted by GitBox <gi...@apache.org>.
nuclearpinguin commented on a change in pull request #7204: [AIRFLOW-XXXX] - add communication chapter to contributing
URL: https://github.com/apache/airflow/pull/7204#discussion_r368311245
 
 

 ##########
 File path: CONTRIBUTING.rst
 ##########
 @@ -664,6 +664,63 @@ Later on
    above depending if you have more commits that cause conflicts in your PR (rebasing applies each
    commit from your PR one-by-one).
 
+How to communicate
+==================
+
+Apache Airflow is a Community within Apache Software Foundation. As the motto of
+the Apache Software Foundation states "Community over Code" - people in the
+community are far more important than the code they create.
+
+This means that communication is very important, and this chapter is all about it.
+
+We have various channel of communication - starting from the official devlist, comments
+in the Pull Requests, Slack, wiki.
+
+All those channels can be used for different purposes:
+
+* The devlist for official communication, discussing proposals, voting, general issues, asking community for
+  opinion etc.
+* Wiki for detailed discussions on big proposals (AIPs) and some helpful, shared resources.
+* PRs for discussing implementation details of this PR (not for architectural discussions)
+* Slack for ad-hoc questions, troubleshooting, occassional discussions, group talks (including SIG - special
+interest groups), notifications, random queries, newbie questions etc.
+
+
+It is important to remember that all contributors, committers and even PMC members are individuals
+that contribute a lot of their free time on top of their work time to Apache Airflow.
+They have families, personal life, sometimes they are swamped with work, sometimes they are on vacations
+sometimes they are simply tired and need a time off. They are in various timezones and their responsiveness
+will vary from time to time. As a community project we have no formal structure, we have no managers nor
+departments and most of the people are autonomous in their opinions and decisions, so sometimes even
+committers will have different opinions on the same subjects.
+
+Disagreements are expected, discussions might include strong opinions and contradicting statements.
+Sometimes you might get two committers asking you to do things differently. This all happened in the past
+and will continue to happen. As a community we have some mechanisms to facilitate discussion and come to
+a consensus, conclusions and sometime we end up voting certain decisions. It is important that those
+decisions are not treated as personal wins or looses - at the end it's the community that we care about
+and what's good for community, should be accepted even if you have different opinion. There is the nice
+motto that you should follow in case you disagree with community decision "Disagree but engage". Even
+if you do not agree with a community decision, you should follow it and embrace (but you are free to
+express your opinion that you don't agree with it).
+
+Here are a few rules that are important to keep in mind when you enter our community:
+
+ * Do not be afraid to ask questions
+ * We have deeply asynchronous communication - do not expect immediate answers, ping people if you are blocked
+ * We have #newbie-questions channel in slack as a safe place to ask questions
+ * You can ask one of the committers to be a mentor for you, they can guide within the community
+ * You can apply to more structured Apache Mentoring Programme
 
 Review comment:
   Should we add link 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.
 
For queries about this service, please contact Infrastructure at:
users@infra.apache.org


With regards,
Apache Git Services

[GitHub] [airflow] nuclearpinguin commented on a change in pull request #7204: [AIRFLOW-XXXX] - add communication chapter to contributing

Posted by GitBox <gi...@apache.org>.
nuclearpinguin commented on a change in pull request #7204: [AIRFLOW-XXXX] - add communication chapter to contributing
URL: https://github.com/apache/airflow/pull/7204#discussion_r368311114
 
 

 ##########
 File path: CONTRIBUTING.rst
 ##########
 @@ -664,6 +664,63 @@ Later on
    above depending if you have more commits that cause conflicts in your PR (rebasing applies each
    commit from your PR one-by-one).
 
+How to communicate
+==================
+
+Apache Airflow is a Community within Apache Software Foundation. As the motto of
+the Apache Software Foundation states "Community over Code" - people in the
+community are far more important than the code they create.
+
+This means that communication is very important, and this chapter is all about it.
+
+We have various channel of communication - starting from the official devlist, comments
+in the Pull Requests, Slack, wiki.
+
+All those channels can be used for different purposes:
+
+* The devlist for official communication, discussing proposals, voting, general issues, asking community for
+  opinion etc.
+* Wiki for detailed discussions on big proposals (AIPs) and some helpful, shared resources.
+* PRs for discussing implementation details of this PR (not for architectural discussions)
+* Slack for ad-hoc questions, troubleshooting, occassional discussions, group talks (including SIG - special
+interest groups), notifications, random queries, newbie questions etc.
+
+
+It is important to remember that all contributors, committers and even PMC members are individuals
+that contribute a lot of their free time on top of their work time to Apache Airflow.
+They have families, personal life, sometimes they are swamped with work, sometimes they are on vacations
 
 Review comment:
   Maybe we should change "they" to "we" to create a stronger bond and avoid deindividuation? Especially that "we" is used later on.

----------------------------------------------------------------
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.
 
For queries about this service, please contact Infrastructure at:
users@infra.apache.org


With regards,
Apache Git Services

[GitHub] [airflow] mschickensoup commented on a change in pull request #7204: [AIRFLOW-XXXX] - add communication chapter to contributing

Posted by GitBox <gi...@apache.org>.
mschickensoup commented on a change in pull request #7204: [AIRFLOW-XXXX] - add communication chapter to contributing
URL: https://github.com/apache/airflow/pull/7204#discussion_r369503677
 
 

 ##########
 File path: CONTRIBUTING.rst
 ##########
 @@ -664,6 +664,63 @@ Later on
    above depending if you have more commits that cause conflicts in your PR (rebasing applies each
    commit from your PR one-by-one).
 
+How to communicate
+==================
+
+Apache Airflow is a Community within Apache Software Foundation. As the motto of
+the Apache Software Foundation states "Community over Code" - people in the
+community are far more important than the code they create.
+
+This means that communication is very important, and this chapter is all about it.
+
+We have various channel of communication - starting from the official devlist, comments
+in the Pull Requests, Slack, wiki.
+
+All those channels can be used for different purposes:
+
+* The devlist for official communication, discussing proposals, voting, general issues, asking community for
+  opinion etc.
+* Wiki for detailed discussions on big proposals (AIPs) and some helpful, shared resources.
+* PRs for discussing implementation details of this PR (not for architectural discussions)
+* Slack for ad-hoc questions, troubleshooting, occassional discussions, group talks (including SIG - special
+interest groups), notifications, random queries, newbie questions etc.
+
+
+It is important to remember that all contributors, committers and even PMC members are individuals
+that contribute a lot of their free time on top of their work time to Apache Airflow.
+They have families, personal life, sometimes they are swamped with work, sometimes they are on vacations
 
 Review comment:
   I know this conversation is marked as resolved but I agree with @nuclearpinguin here. At the moment, a message sounds as if committers or PMC members were gods and we shouldn't bother them because they have private lives  😄 Everyone does have private life / duties etc. In general I'd make the whole paragraph shorter and more concise. The core message in my opinion should be about: 
   ```suggestion
   We are all devoting our time for community as individuals who except for being active in Apache Airflow have families, daily jobs, right for vacation. Sometimes we are in different time zones or simply are busiy with day-to-day duties that our response time might be delayed. For us it's crucial to remember to respect each other in the project with no formal structure. There are no managers, departments, most of us is autonomous in our opinions, decisions. All of it makes Apache Airflow community a great space for open discussion and mutual respect for various opinions. 
   ``` 

----------------------------------------------------------------
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.
 
For queries about this service, please contact Infrastructure at:
users@infra.apache.org


With regards,
Apache Git Services

[GitHub] [airflow] mschickensoup commented on a change in pull request #7204: [AIRFLOW-XXXX] - add communication chapter to contributing

Posted by GitBox <gi...@apache.org>.
mschickensoup commented on a change in pull request #7204: [AIRFLOW-XXXX] - add communication chapter to contributing
URL: https://github.com/apache/airflow/pull/7204#discussion_r369634841
 
 

 ##########
 File path: CONTRIBUTING.rst
 ##########
 @@ -664,6 +664,73 @@ Later on
    above depending if you have more commits that cause conflicts in your PR (rebasing applies each
    commit from your PR one-by-one).
 
+How to communicate
+==================
+
+Apache Airflow is a Community within Apache Software Foundation. As the motto of
+the Apache Software Foundation states "Community over Code" - people in the
+community are far more important than their contribution.
+
+This means that communication is very important, and this chapter is all about it.
+
+We have various channel of communication - starting from the official devlist, comments
+in the Pull Requests, Slack, wiki.
+
+All those channels can be used for different purposes:
+
+* The devlist for official communication, discussing proposals, voting, general issues, asking community for
+  opinion etc.
+* Wiki for detailed discussions on big proposals (AIPs) and some helpful, shared resources.
+* PRs for discussing implementation details of this PR (not for architectural discussions)
+* Slack for ad-hoc questions, troubleshooting, occassional discussions, group talks (including SIG - special
+interest groups), notifications, random queries, newbie questions etc.
+
+
+It is important to remember that all contributors, committers and even PMC members are individuals
+that contribute a lot of their free time on top of their work time to develop Apache Airflow.
+They have families, personal life, sometimes they are swamped with work, sometimes they are on vacations
+sometimes they are simply tired and need a time off. They are in various timezones and their responsiveness
+will vary from time to time. As a community project we have no formal structure, we have no managers nor
+departments and most of the people are autonomous in their opinions and decisions, so sometimes even
+committers will have different opinions on the same subjects.
+
+Disagreements are expected, discussions might include strong opinions and contradicting statements.
+Sometimes you might get two committers asking you to do things differently. This all happened in the past
+and will continue to happen. As a community we have some mechanisms to facilitate discussion and come to
+a consensus, conclusions and sometime we end up voting certain decisions. It is important that those
 
 Review comment:
   ```suggestion
   a consensus, conclusions or we end up voting to make certain decisions. It is important that these
   ```

----------------------------------------------------------------
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.
 
For queries about this service, please contact Infrastructure at:
users@infra.apache.org


With regards,
Apache Git Services

[GitHub] [airflow] mschickensoup commented on a change in pull request #7204: [AIRFLOW-XXXX] - add communication chapter to contributing

Posted by GitBox <gi...@apache.org>.
mschickensoup commented on a change in pull request #7204: [AIRFLOW-XXXX] - add communication chapter to contributing
URL: https://github.com/apache/airflow/pull/7204#discussion_r369636196
 
 

 ##########
 File path: CONTRIBUTING.rst
 ##########
 @@ -664,6 +664,73 @@ Later on
    above depending if you have more commits that cause conflicts in your PR (rebasing applies each
    commit from your PR one-by-one).
 
+How to communicate
+==================
+
+Apache Airflow is a Community within Apache Software Foundation. As the motto of
+the Apache Software Foundation states "Community over Code" - people in the
+community are far more important than their contribution.
+
+This means that communication is very important, and this chapter is all about it.
+
+We have various channel of communication - starting from the official devlist, comments
+in the Pull Requests, Slack, wiki.
+
+All those channels can be used for different purposes:
+
+* The devlist for official communication, discussing proposals, voting, general issues, asking community for
+  opinion etc.
+* Wiki for detailed discussions on big proposals (AIPs) and some helpful, shared resources.
+* PRs for discussing implementation details of this PR (not for architectural discussions)
+* Slack for ad-hoc questions, troubleshooting, occassional discussions, group talks (including SIG - special
+interest groups), notifications, random queries, newbie questions etc.
+
+
+It is important to remember that all contributors, committers and even PMC members are individuals
+that contribute a lot of their free time on top of their work time to develop Apache Airflow.
+They have families, personal life, sometimes they are swamped with work, sometimes they are on vacations
+sometimes they are simply tired and need a time off. They are in various timezones and their responsiveness
+will vary from time to time. As a community project we have no formal structure, we have no managers nor
+departments and most of the people are autonomous in their opinions and decisions, so sometimes even
+committers will have different opinions on the same subjects.
+
+Disagreements are expected, discussions might include strong opinions and contradicting statements.
+Sometimes you might get two committers asking you to do things differently. This all happened in the past
+and will continue to happen. As a community we have some mechanisms to facilitate discussion and come to
+a consensus, conclusions and sometime we end up voting certain decisions. It is important that those
+decisions are not treated as personal wins or looses. At the end it's the community that we all care about
+and what's good for community, should be accepted even if you have different opinion. There is the nice
+motto that you should follow in case you disagree with community decision "Disagree but engage". Even
+if you do not agree with a community decision, you should follow it and embrace (but you are free to
+express your opinion that you don't agree with it).
+
+As a community - we have high requirements for code quality. This is mainly because we are a distributed
+and loosely organised team - sometime we have contributors that commit one commit only, sometimes people add
 
 Review comment:
   ```suggestion
   and loosely organised team - we have both contributors that commit one commit only and people who add
   ```

----------------------------------------------------------------
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.
 
For queries about this service, please contact Infrastructure at:
users@infra.apache.org


With regards,
Apache Git Services

[GitHub] [airflow] tooptoop4 commented on a change in pull request #7204: [AIRFLOW-XXXX] - add communication chapter to contributing

Posted by GitBox <gi...@apache.org>.
tooptoop4 commented on a change in pull request #7204: [AIRFLOW-XXXX] - add communication chapter to contributing
URL: https://github.com/apache/airflow/pull/7204#discussion_r368236477
 
 

 ##########
 File path: CONTRIBUTING.rst
 ##########
 @@ -567,6 +567,63 @@ Step 5: Pass PR Review
 Note that committers will use **Squash and Merge** instead of **Rebase and Merge**
 when merging PRs and your commit will be squashed to single commit.
 
+Communication
+=============
+
+Apache Airflow is a Community within Apache Software Foundation. As the motto of
+the Apache Software Foundation states "Community over Code" - people in the
+community are far more important than the code they create.
+
+This means that communication is very important, and this chapter is all about it.
+
+We have various channel of communication - starting from the official devlist, comments
+in the Pull Requests, Slack, wiki.
+
+All those channels can be used for different purposes:
+
+* The devlist for official communication, discussing proposals, voting, general issues, asking community for
+  opinion etc.
+* Wiki for detailed discussions on big proposals (AIPs) and some helpful, shared resources.
+* PRs for discussing implementation details of this PR (not for architectural discussions)
+* Slack for ad-hoc questions, troubleshooting, occassional discussions, group talks (including SIG - special
+interest groups), notifications, random queries, newbie questions etc.
+
+
+It is important to remember that all contributors, committers and even PMC members are individuals
+that contribute a lot of their free time on top of their work time to Apache Airflow.
+They have families, personal life, sometimes they are swamped with work, sometimes they are on vacations
+sometimes they are simply tired and need a time off. They are in various timezones and their responsiveness
+will vary from time to time. As a community project we have no formal structure, we have no managers nor
+departments and most of the people are autonomous in their opinions and decisions, so sometimes even
+committers will have different opinions on the same subjects.
+
+Disagreements are expected, discussions might include strong opinions and contradicting statements.
+Sometimes you might get two committers asking you to do things differently. This all happened in the past
+and will continue to happen. As a community we have some mechanisms to facilitate discussion and come to
+a consesus, conclusions and sometime we end up voting certain decisions. It is important that those
+decisions are not treated as personal wins or looses - at the end it's the community that we care about
+and what's good for community, should be accepted even if you have different opinion. There is the nice
+motto that you should follow in case you disagree with community decision "Disagree but engage". Even
+if you do not agree with a community decision, you should follow it and embrace (but you are free to
+express your opinion that you don't agree with it).
+
+Here are a few rules that are important to keep in mind when you enter our community:
+
+ * Do not be afraid to ask questions
+ * We have deeply asynchronous communication - do not expect immediate answers, ping people if you are blocked
+ * We have #newbie-questions channel in slack as a safe place to ask questions
+ * You can ask one of the committers to be a mentor for you, they can guide within the community
+ * You can apply to more structured Apache Mentoring Programme
+ * It’s your responsibility as an author to take your PR from start-to-end including leading communication
+   in the PR
+ * It’s your responsibility as an author to ping committers to review your PR - be mildly annoying sometimes,
+   it’s OK to be slightly annoying with your change - it iis also a sign for committers that you care
 
 Review comment:
   iis

----------------------------------------------------------------
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.
 
For queries about this service, please contact Infrastructure at:
users@infra.apache.org


With regards,
Apache Git Services

[GitHub] [airflow] mschickensoup commented on a change in pull request #7204: [AIRFLOW-XXXX] - add communication chapter to contributing

Posted by GitBox <gi...@apache.org>.
mschickensoup commented on a change in pull request #7204: [AIRFLOW-XXXX] - add communication chapter to contributing
URL: https://github.com/apache/airflow/pull/7204#discussion_r369638493
 
 

 ##########
 File path: CONTRIBUTING.rst
 ##########
 @@ -664,6 +664,73 @@ Later on
    above depending if you have more commits that cause conflicts in your PR (rebasing applies each
    commit from your PR one-by-one).
 
+How to communicate
+==================
+
+Apache Airflow is a Community within Apache Software Foundation. As the motto of
+the Apache Software Foundation states "Community over Code" - people in the
+community are far more important than their contribution.
+
+This means that communication is very important, and this chapter is all about it.
+
+We have various channel of communication - starting from the official devlist, comments
+in the Pull Requests, Slack, wiki.
+
+All those channels can be used for different purposes:
+
+* The devlist for official communication, discussing proposals, voting, general issues, asking community for
+  opinion etc.
+* Wiki for detailed discussions on big proposals (AIPs) and some helpful, shared resources.
+* PRs for discussing implementation details of this PR (not for architectural discussions)
+* Slack for ad-hoc questions, troubleshooting, occassional discussions, group talks (including SIG - special
+interest groups), notifications, random queries, newbie questions etc.
+
+
+It is important to remember that all contributors, committers and even PMC members are individuals
+that contribute a lot of their free time on top of their work time to develop Apache Airflow.
+They have families, personal life, sometimes they are swamped with work, sometimes they are on vacations
+sometimes they are simply tired and need a time off. They are in various timezones and their responsiveness
+will vary from time to time. As a community project we have no formal structure, we have no managers nor
+departments and most of the people are autonomous in their opinions and decisions, so sometimes even
+committers will have different opinions on the same subjects.
+
+Disagreements are expected, discussions might include strong opinions and contradicting statements.
+Sometimes you might get two committers asking you to do things differently. This all happened in the past
+and will continue to happen. As a community we have some mechanisms to facilitate discussion and come to
+a consensus, conclusions and sometime we end up voting certain decisions. It is important that those
+decisions are not treated as personal wins or looses. At the end it's the community that we all care about
+and what's good for community, should be accepted even if you have different opinion. There is the nice
+motto that you should follow in case you disagree with community decision "Disagree but engage". Even
+if you do not agree with a community decision, you should follow it and embrace (but you are free to
+express your opinion that you don't agree with it).
+
+As a community - we have high requirements for code quality. This is mainly because we are a distributed
+and loosely organised team - sometime we have contributors that commit one commit only, sometimes people add
+more commits, sometimes people assume informal "stewardship" over parts of code for some time - but at any
+time we should be sure that the code can be taken over by others - without excessive communication. Setting
+high requirements for the code (fairly strict code review, static code checks, requirements of automated
+tests, pre-commit checks ) is the best way that we can achieve that - by only accepting good quality
 
 Review comment:
   ```suggestion
   tests, pre-commit checks) is the best way to achieve that - by only accepting top-notch quality
   ```

----------------------------------------------------------------
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.
 
For queries about this service, please contact Infrastructure at:
users@infra.apache.org


With regards,
Apache Git Services

[GitHub] [airflow] potiuk commented on a change in pull request #7204: [AIRFLOW-XXXX] - add communication chapter to contributing

Posted by GitBox <gi...@apache.org>.
potiuk commented on a change in pull request #7204: [AIRFLOW-XXXX] - add communication chapter to contributing
URL: https://github.com/apache/airflow/pull/7204#discussion_r368527769
 
 

 ##########
 File path: CONTRIBUTING.rst
 ##########
 @@ -664,6 +664,63 @@ Later on
    above depending if you have more commits that cause conflicts in your PR (rebasing applies each
    commit from your PR one-by-one).
 
+How to communicate
+==================
+
+Apache Airflow is a Community within Apache Software Foundation. As the motto of
+the Apache Software Foundation states "Community over Code" - people in the
+community are far more important than the code they create.
+
+This means that communication is very important, and this chapter is all about it.
+
+We have various channel of communication - starting from the official devlist, comments
+in the Pull Requests, Slack, wiki.
+
+All those channels can be used for different purposes:
+
+* The devlist for official communication, discussing proposals, voting, general issues, asking community for
+  opinion etc.
+* Wiki for detailed discussions on big proposals (AIPs) and some helpful, shared resources.
+* PRs for discussing implementation details of this PR (not for architectural discussions)
+* Slack for ad-hoc questions, troubleshooting, occassional discussions, group talks (including SIG - special
+interest groups), notifications, random queries, newbie questions etc.
+
+
+It is important to remember that all contributors, committers and even PMC members are individuals
+that contribute a lot of their free time on top of their work time to Apache Airflow.
+They have families, personal life, sometimes they are swamped with work, sometimes they are on vacations
+sometimes they are simply tired and need a time off. They are in various timezones and their responsiveness
+will vary from time to time. As a community project we have no formal structure, we have no managers nor
+departments and most of the people are autonomous in their opinions and decisions, so sometimes even
+committers will have different opinions on the same subjects.
+
+Disagreements are expected, discussions might include strong opinions and contradicting statements.
+Sometimes you might get two committers asking you to do things differently. This all happened in the past
+and will continue to happen. As a community we have some mechanisms to facilitate discussion and come to
+a consensus, conclusions and sometime we end up voting certain decisions. It is important that those
+decisions are not treated as personal wins or looses - at the end it's the community that we care about
+and what's good for community, should be accepted even if you have different opinion. There is the nice
+motto that you should follow in case you disagree with community decision "Disagree but engage". Even
+if you do not agree with a community decision, you should follow it and embrace (but you are free to
+express your opinion that you don't agree with it).
+
+Here are a few rules that are important to keep in mind when you enter our community:
+
+ * Do not be afraid to ask questions
+ * We have deeply asynchronous communication - do not expect immediate answers, ping people if you are blocked
+ * We have #newbie-questions channel in slack as a safe place to ask questions
+ * You can ask one of the committers to be a mentor for you, they can guide within the community
+ * You can apply to more structured Apache Mentoring Programme
+ * It’s your responsibility as an author to take your PR from start-to-end including leading communication
+   in the PR
+ * It’s your responsibility as an author to ping committers to review your PR - be mildly annoying sometimes,
+   it’s OK to be slightly annoying with your change - it is also a sign for committers that you care
+ * We have high-bar set for the code requirements - be considerate to those requirements
 
 Review comment:
   Added it as a chapter above

----------------------------------------------------------------
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.
 
For queries about this service, please contact Infrastructure at:
users@infra.apache.org


With regards,
Apache Git Services

[GitHub] [airflow] mschickensoup commented on a change in pull request #7204: [AIRFLOW-XXXX] - add communication chapter to contributing

Posted by GitBox <gi...@apache.org>.
mschickensoup commented on a change in pull request #7204: [AIRFLOW-XXXX] - add communication chapter to contributing
URL: https://github.com/apache/airflow/pull/7204#discussion_r369121248
 
 

 ##########
 File path: CONTRIBUTING.rst
 ##########
 @@ -664,6 +664,73 @@ Later on
    above depending if you have more commits that cause conflicts in your PR (rebasing applies each
    commit from your PR one-by-one).
 
+How to communicate
+==================
+
+Apache Airflow is a Community within Apache Software Foundation. As the motto of
+the Apache Software Foundation states "Community over Code" - people in the
+community are far more important than their contribution.
+
+This means that communication is very important, and this chapter is all about it.
 
 Review comment:
   ```suggestion
   This means that communication is very important, and this chapter is all about it.
   ```
   This means that communication plays the big role in it, and this chapter is all about 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.
 
For queries about this service, please contact Infrastructure at:
users@infra.apache.org


With regards,
Apache Git Services

[GitHub] [airflow] potiuk commented on a change in pull request #7204: [AIRFLOW-XXXX] - add communication chapter to contributing

Posted by GitBox <gi...@apache.org>.
potiuk commented on a change in pull request #7204: [AIRFLOW-XXXX] - add communication chapter to contributing
URL: https://github.com/apache/airflow/pull/7204#discussion_r380396906
 
 

 ##########
 File path: CONTRIBUTING.rst
 ##########
 @@ -664,6 +664,73 @@ Later on
    above depending if you have more commits that cause conflicts in your PR (rebasing applies each
    commit from your PR one-by-one).
 
+How to communicate
+==================
+
+Apache Airflow is a Community within Apache Software Foundation. As the motto of
+the Apache Software Foundation states "Community over Code" - people in the
+community are far more important than their contribution.
+
+This means that communication is very important, and this chapter is all about it.
+
+We have various channel of communication - starting from the official devlist, comments
+in the Pull Requests, Slack, wiki.
+
+All those channels can be used for different purposes:
+
+* The devlist for official communication, discussing proposals, voting, general issues, asking community for
+  opinion etc.
+* Wiki for detailed discussions on big proposals (AIPs) and some helpful, shared resources.
+* PRs for discussing implementation details of this PR (not for architectural discussions)
+* Slack for ad-hoc questions, troubleshooting, occassional discussions, group talks (including SIG - special
+interest groups), notifications, random queries, newbie questions etc.
+
+
+It is important to remember that all contributors, committers and even PMC members are individuals
+that contribute a lot of their free time on top of their work time to develop Apache Airflow.
+They have families, personal life, sometimes they are swamped with work, sometimes they are on vacations
+sometimes they are simply tired and need a time off. They are in various timezones and their responsiveness
+will vary from time to time. As a community project we have no formal structure, we have no managers nor
+departments and most of the people are autonomous in their opinions and decisions, so sometimes even
+committers will have different opinions on the same subjects.
 
 Review comment:
   Agreed.!

----------------------------------------------------------------
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.
 
For queries about this service, please contact Infrastructure at:
users@infra.apache.org


With regards,
Apache Git Services

[GitHub] [airflow] nuclearpinguin commented on a change in pull request #7204: [AIRFLOW-XXXX] - add communication chapter to contributing

Posted by GitBox <gi...@apache.org>.
nuclearpinguin commented on a change in pull request #7204: [AIRFLOW-XXXX] - add communication chapter to contributing
URL: https://github.com/apache/airflow/pull/7204#discussion_r368311322
 
 

 ##########
 File path: CONTRIBUTING.rst
 ##########
 @@ -664,6 +664,63 @@ Later on
    above depending if you have more commits that cause conflicts in your PR (rebasing applies each
    commit from your PR one-by-one).
 
+How to communicate
+==================
+
+Apache Airflow is a Community within Apache Software Foundation. As the motto of
+the Apache Software Foundation states "Community over Code" - people in the
+community are far more important than the code they create.
+
+This means that communication is very important, and this chapter is all about it.
+
+We have various channel of communication - starting from the official devlist, comments
+in the Pull Requests, Slack, wiki.
+
+All those channels can be used for different purposes:
+
+* The devlist for official communication, discussing proposals, voting, general issues, asking community for
+  opinion etc.
+* Wiki for detailed discussions on big proposals (AIPs) and some helpful, shared resources.
+* PRs for discussing implementation details of this PR (not for architectural discussions)
+* Slack for ad-hoc questions, troubleshooting, occassional discussions, group talks (including SIG - special
+interest groups), notifications, random queries, newbie questions etc.
+
+
+It is important to remember that all contributors, committers and even PMC members are individuals
+that contribute a lot of their free time on top of their work time to Apache Airflow.
+They have families, personal life, sometimes they are swamped with work, sometimes they are on vacations
+sometimes they are simply tired and need a time off. They are in various timezones and their responsiveness
+will vary from time to time. As a community project we have no formal structure, we have no managers nor
+departments and most of the people are autonomous in their opinions and decisions, so sometimes even
+committers will have different opinions on the same subjects.
+
+Disagreements are expected, discussions might include strong opinions and contradicting statements.
+Sometimes you might get two committers asking you to do things differently. This all happened in the past
+and will continue to happen. As a community we have some mechanisms to facilitate discussion and come to
+a consensus, conclusions and sometime we end up voting certain decisions. It is important that those
+decisions are not treated as personal wins or looses - at the end it's the community that we care about
+and what's good for community, should be accepted even if you have different opinion. There is the nice
+motto that you should follow in case you disagree with community decision "Disagree but engage". Even
+if you do not agree with a community decision, you should follow it and embrace (but you are free to
+express your opinion that you don't agree with it).
+
+Here are a few rules that are important to keep in mind when you enter our community:
+
+ * Do not be afraid to ask questions
+ * We have deeply asynchronous communication - do not expect immediate answers, ping people if you are blocked
+ * We have #newbie-questions channel in slack as a safe place to ask questions
+ * You can ask one of the committers to be a mentor for you, they can guide within the community
+ * You can apply to more structured Apache Mentoring Programme
+ * It’s your responsibility as an author to take your PR from start-to-end including leading communication
+   in the PR
+ * It’s your responsibility as an author to ping committers to review your PR - be mildly annoying sometimes,
+   it’s OK to be slightly annoying with your change - it is also a sign for committers that you care
+ * We have high-bar set for the code requirements - be considerate to those requirements
+ * If in doubt - ask community for their opinions and sometimes voting at the devlist
 
 Review comment:
   ```suggestion
    * If in doubt - ask the community for their opinion or propose to vote at 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.
 
For queries about this service, please contact Infrastructure at:
users@infra.apache.org


With regards,
Apache Git Services

[GitHub] [airflow] mschickensoup commented on a change in pull request #7204: [AIRFLOW-XXXX] - add communication chapter to contributing

Posted by GitBox <gi...@apache.org>.
mschickensoup commented on a change in pull request #7204: [AIRFLOW-XXXX] - add communication chapter to contributing
URL: https://github.com/apache/airflow/pull/7204#discussion_r369636858
 
 

 ##########
 File path: CONTRIBUTING.rst
 ##########
 @@ -664,6 +664,73 @@ Later on
    above depending if you have more commits that cause conflicts in your PR (rebasing applies each
    commit from your PR one-by-one).
 
+How to communicate
+==================
+
+Apache Airflow is a Community within Apache Software Foundation. As the motto of
+the Apache Software Foundation states "Community over Code" - people in the
+community are far more important than their contribution.
+
+This means that communication is very important, and this chapter is all about it.
+
+We have various channel of communication - starting from the official devlist, comments
+in the Pull Requests, Slack, wiki.
+
+All those channels can be used for different purposes:
+
+* The devlist for official communication, discussing proposals, voting, general issues, asking community for
+  opinion etc.
+* Wiki for detailed discussions on big proposals (AIPs) and some helpful, shared resources.
+* PRs for discussing implementation details of this PR (not for architectural discussions)
+* Slack for ad-hoc questions, troubleshooting, occassional discussions, group talks (including SIG - special
+interest groups), notifications, random queries, newbie questions etc.
+
+
+It is important to remember that all contributors, committers and even PMC members are individuals
+that contribute a lot of their free time on top of their work time to develop Apache Airflow.
+They have families, personal life, sometimes they are swamped with work, sometimes they are on vacations
+sometimes they are simply tired and need a time off. They are in various timezones and their responsiveness
+will vary from time to time. As a community project we have no formal structure, we have no managers nor
+departments and most of the people are autonomous in their opinions and decisions, so sometimes even
+committers will have different opinions on the same subjects.
+
+Disagreements are expected, discussions might include strong opinions and contradicting statements.
+Sometimes you might get two committers asking you to do things differently. This all happened in the past
+and will continue to happen. As a community we have some mechanisms to facilitate discussion and come to
+a consensus, conclusions and sometime we end up voting certain decisions. It is important that those
+decisions are not treated as personal wins or looses. At the end it's the community that we all care about
+and what's good for community, should be accepted even if you have different opinion. There is the nice
+motto that you should follow in case you disagree with community decision "Disagree but engage". Even
+if you do not agree with a community decision, you should follow it and embrace (but you are free to
+express your opinion that you don't agree with it).
+
+As a community - we have high requirements for code quality. This is mainly because we are a distributed
+and loosely organised team - sometime we have contributors that commit one commit only, sometimes people add
+more commits, sometimes people assume informal "stewardship" over parts of code for some time - but at any
+time we should be sure that the code can be taken over by others - without excessive communication. Setting
 
 Review comment:
   ```suggestion
   time we should make sure that the code can be taken over by others - without excessive communication. Setting
   ```

----------------------------------------------------------------
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.
 
For queries about this service, please contact Infrastructure at:
users@infra.apache.org


With regards,
Apache Git Services

[GitHub] [airflow] potiuk commented on a change in pull request #7204: [AIRFLOW-XXXX] - add communication chapter to contributing

Posted by GitBox <gi...@apache.org>.
potiuk commented on a change in pull request #7204: [AIRFLOW-XXXX] - add communication chapter to contributing
URL: https://github.com/apache/airflow/pull/7204#discussion_r380397958
 
 

 ##########
 File path: CONTRIBUTING.rst
 ##########
 @@ -664,6 +664,73 @@ Later on
    above depending if you have more commits that cause conflicts in your PR (rebasing applies each
    commit from your PR one-by-one).
 
+How to communicate
+==================
+
+Apache Airflow is a Community within Apache Software Foundation. As the motto of
+the Apache Software Foundation states "Community over Code" - people in the
+community are far more important than their contribution.
+
+This means that communication is very important, and this chapter is all about it.
+
+We have various channel of communication - starting from the official devlist, comments
+in the Pull Requests, Slack, wiki.
+
+All those channels can be used for different purposes:
+
+* The devlist for official communication, discussing proposals, voting, general issues, asking community for
+  opinion etc.
+* Wiki for detailed discussions on big proposals (AIPs) and some helpful, shared resources.
+* PRs for discussing implementation details of this PR (not for architectural discussions)
+* Slack for ad-hoc questions, troubleshooting, occassional discussions, group talks (including SIG - special
+interest groups), notifications, random queries, newbie questions etc.
+
+
+It is important to remember that all contributors, committers and even PMC members are individuals
+that contribute a lot of their free time on top of their work time to develop Apache Airflow.
+They have families, personal life, sometimes they are swamped with work, sometimes they are on vacations
+sometimes they are simply tired and need a time off. They are in various timezones and their responsiveness
+will vary from time to time. As a community project we have no formal structure, we have no managers nor
+departments and most of the people are autonomous in their opinions and decisions, so sometimes even
+committers will have different opinions on the same subjects.
+
+Disagreements are expected, discussions might include strong opinions and contradicting statements.
+Sometimes you might get two committers asking you to do things differently. This all happened in the past
+and will continue to happen. As a community we have some mechanisms to facilitate discussion and come to
+a consensus, conclusions and sometime we end up voting certain decisions. It is important that those
+decisions are not treated as personal wins or looses. At the end it's the community that we all care about
+and what's good for community, should be accepted even if you have different opinion. There is the nice
 
 Review comment:
   Done

----------------------------------------------------------------
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.
 
For queries about this service, please contact Infrastructure at:
users@infra.apache.org


With regards,
Apache Git Services

[GitHub] [airflow] mschickensoup commented on a change in pull request #7204: [AIRFLOW-XXXX] - add communication chapter to contributing

Posted by GitBox <gi...@apache.org>.
mschickensoup commented on a change in pull request #7204: [AIRFLOW-XXXX] - add communication chapter to contributing
URL: https://github.com/apache/airflow/pull/7204#discussion_r369636735
 
 

 ##########
 File path: CONTRIBUTING.rst
 ##########
 @@ -664,6 +664,73 @@ Later on
    above depending if you have more commits that cause conflicts in your PR (rebasing applies each
    commit from your PR one-by-one).
 
+How to communicate
+==================
+
+Apache Airflow is a Community within Apache Software Foundation. As the motto of
+the Apache Software Foundation states "Community over Code" - people in the
+community are far more important than their contribution.
+
+This means that communication is very important, and this chapter is all about it.
+
+We have various channel of communication - starting from the official devlist, comments
+in the Pull Requests, Slack, wiki.
+
+All those channels can be used for different purposes:
+
+* The devlist for official communication, discussing proposals, voting, general issues, asking community for
+  opinion etc.
+* Wiki for detailed discussions on big proposals (AIPs) and some helpful, shared resources.
+* PRs for discussing implementation details of this PR (not for architectural discussions)
+* Slack for ad-hoc questions, troubleshooting, occassional discussions, group talks (including SIG - special
+interest groups), notifications, random queries, newbie questions etc.
+
+
+It is important to remember that all contributors, committers and even PMC members are individuals
+that contribute a lot of their free time on top of their work time to develop Apache Airflow.
+They have families, personal life, sometimes they are swamped with work, sometimes they are on vacations
+sometimes they are simply tired and need a time off. They are in various timezones and their responsiveness
+will vary from time to time. As a community project we have no formal structure, we have no managers nor
+departments and most of the people are autonomous in their opinions and decisions, so sometimes even
+committers will have different opinions on the same subjects.
+
+Disagreements are expected, discussions might include strong opinions and contradicting statements.
+Sometimes you might get two committers asking you to do things differently. This all happened in the past
+and will continue to happen. As a community we have some mechanisms to facilitate discussion and come to
+a consensus, conclusions and sometime we end up voting certain decisions. It is important that those
+decisions are not treated as personal wins or looses. At the end it's the community that we all care about
+and what's good for community, should be accepted even if you have different opinion. There is the nice
+motto that you should follow in case you disagree with community decision "Disagree but engage". Even
+if you do not agree with a community decision, you should follow it and embrace (but you are free to
+express your opinion that you don't agree with it).
+
+As a community - we have high requirements for code quality. This is mainly because we are a distributed
+and loosely organised team - sometime we have contributors that commit one commit only, sometimes people add
+more commits, sometimes people assume informal "stewardship" over parts of code for some time - but at any
 
 Review comment:
   ```suggestion
   more commits. It happens that some people assume informal "stewardship" over parts of code - but at any
   ```

----------------------------------------------------------------
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.
 
For queries about this service, please contact Infrastructure at:
users@infra.apache.org


With regards,
Apache Git Services

[GitHub] [airflow] potiuk commented on a change in pull request #7204: [AIRFLOW-XXXX] - add communication chapter to contributing

Posted by GitBox <gi...@apache.org>.
potiuk commented on a change in pull request #7204: [AIRFLOW-XXXX] - add communication chapter to contributing
URL: https://github.com/apache/airflow/pull/7204#discussion_r380396248
 
 

 ##########
 File path: CONTRIBUTING.rst
 ##########
 @@ -664,6 +664,73 @@ Later on
    above depending if you have more commits that cause conflicts in your PR (rebasing applies each
    commit from your PR one-by-one).
 
+How to communicate
+==================
+
+Apache Airflow is a Community within Apache Software Foundation. As the motto of
+the Apache Software Foundation states "Community over Code" - people in the
+community are far more important than their contribution.
+
+This means that communication is very important, and this chapter is all about it.
+
+We have various channel of communication - starting from the official devlist, comments
+in the Pull Requests, Slack, wiki.
+
+All those channels can be used for different purposes:
+
+* The devlist for official communication, discussing proposals, voting, general issues, asking community for
+  opinion etc.
+* Wiki for detailed discussions on big proposals (AIPs) and some helpful, shared resources.
+* PRs for discussing implementation details of this PR (not for architectural discussions)
+* Slack for ad-hoc questions, troubleshooting, occassional discussions, group talks (including SIG - special
+interest groups), notifications, random queries, newbie questions etc.
 
 Review comment:
   * Those will be bullet points on second level
   * I added links to all the channels
   * I added information about the prefixes

----------------------------------------------------------------
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.
 
For queries about this service, please contact Infrastructure at:
users@infra.apache.org


With regards,
Apache Git Services

[GitHub] [airflow] potiuk commented on issue #7204: [AIRFLOW-XXXX] - add communication chapter to contributing

Posted by GitBox <gi...@apache.org>.
potiuk commented on issue #7204: [AIRFLOW-XXXX] - add communication chapter to contributing
URL: https://github.com/apache/airflow/pull/7204#issuecomment-587213272
 
 
   thanks @mschickensoup  for 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.
 
For queries about this service, please contact Infrastructure at:
users@infra.apache.org


With regards,
Apache Git Services

[GitHub] [airflow] nuclearpinguin commented on a change in pull request #7204: [AIRFLOW-XXXX] - add communication chapter to contributing

Posted by GitBox <gi...@apache.org>.
nuclearpinguin commented on a change in pull request #7204: [AIRFLOW-XXXX] - add communication chapter to contributing
URL: https://github.com/apache/airflow/pull/7204#discussion_r368311203
 
 

 ##########
 File path: CONTRIBUTING.rst
 ##########
 @@ -664,6 +664,63 @@ Later on
    above depending if you have more commits that cause conflicts in your PR (rebasing applies each
    commit from your PR one-by-one).
 
+How to communicate
+==================
+
+Apache Airflow is a Community within Apache Software Foundation. As the motto of
+the Apache Software Foundation states "Community over Code" - people in the
+community are far more important than the code they create.
+
+This means that communication is very important, and this chapter is all about it.
+
+We have various channel of communication - starting from the official devlist, comments
+in the Pull Requests, Slack, wiki.
+
+All those channels can be used for different purposes:
+
+* The devlist for official communication, discussing proposals, voting, general issues, asking community for
+  opinion etc.
+* Wiki for detailed discussions on big proposals (AIPs) and some helpful, shared resources.
+* PRs for discussing implementation details of this PR (not for architectural discussions)
+* Slack for ad-hoc questions, troubleshooting, occassional discussions, group talks (including SIG - special
+interest groups), notifications, random queries, newbie questions etc.
+
+
+It is important to remember that all contributors, committers and even PMC members are individuals
+that contribute a lot of their free time on top of their work time to Apache Airflow.
+They have families, personal life, sometimes they are swamped with work, sometimes they are on vacations
+sometimes they are simply tired and need a time off. They are in various timezones and their responsiveness
+will vary from time to time. As a community project we have no formal structure, we have no managers nor
+departments and most of the people are autonomous in their opinions and decisions, so sometimes even
+committers will have different opinions on the same subjects.
+
+Disagreements are expected, discussions might include strong opinions and contradicting statements.
+Sometimes you might get two committers asking you to do things differently. This all happened in the past
+and will continue to happen. As a community we have some mechanisms to facilitate discussion and come to
+a consensus, conclusions and sometime we end up voting certain decisions. It is important that those
+decisions are not treated as personal wins or looses - at the end it's the community that we care about
 
 Review comment:
   ```suggestion
   decisions are not treated as personal wins or looses. At the end it's the community that we all care about
   ```

----------------------------------------------------------------
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.
 
For queries about this service, please contact Infrastructure at:
users@infra.apache.org


With regards,
Apache Git Services

[GitHub] [airflow] nuclearpinguin commented on a change in pull request #7204: [AIRFLOW-XXXX] - add communication chapter to contributing

Posted by GitBox <gi...@apache.org>.
nuclearpinguin commented on a change in pull request #7204: [AIRFLOW-XXXX] - add communication chapter to contributing
URL: https://github.com/apache/airflow/pull/7204#discussion_r368311302
 
 

 ##########
 File path: CONTRIBUTING.rst
 ##########
 @@ -664,6 +664,63 @@ Later on
    above depending if you have more commits that cause conflicts in your PR (rebasing applies each
    commit from your PR one-by-one).
 
+How to communicate
+==================
+
+Apache Airflow is a Community within Apache Software Foundation. As the motto of
+the Apache Software Foundation states "Community over Code" - people in the
+community are far more important than the code they create.
+
+This means that communication is very important, and this chapter is all about it.
+
+We have various channel of communication - starting from the official devlist, comments
+in the Pull Requests, Slack, wiki.
+
+All those channels can be used for different purposes:
+
+* The devlist for official communication, discussing proposals, voting, general issues, asking community for
+  opinion etc.
+* Wiki for detailed discussions on big proposals (AIPs) and some helpful, shared resources.
+* PRs for discussing implementation details of this PR (not for architectural discussions)
+* Slack for ad-hoc questions, troubleshooting, occassional discussions, group talks (including SIG - special
+interest groups), notifications, random queries, newbie questions etc.
+
+
+It is important to remember that all contributors, committers and even PMC members are individuals
+that contribute a lot of their free time on top of their work time to Apache Airflow.
+They have families, personal life, sometimes they are swamped with work, sometimes they are on vacations
+sometimes they are simply tired and need a time off. They are in various timezones and their responsiveness
+will vary from time to time. As a community project we have no formal structure, we have no managers nor
+departments and most of the people are autonomous in their opinions and decisions, so sometimes even
+committers will have different opinions on the same subjects.
+
+Disagreements are expected, discussions might include strong opinions and contradicting statements.
+Sometimes you might get two committers asking you to do things differently. This all happened in the past
+and will continue to happen. As a community we have some mechanisms to facilitate discussion and come to
+a consensus, conclusions and sometime we end up voting certain decisions. It is important that those
+decisions are not treated as personal wins or looses - at the end it's the community that we care about
+and what's good for community, should be accepted even if you have different opinion. There is the nice
+motto that you should follow in case you disagree with community decision "Disagree but engage". Even
+if you do not agree with a community decision, you should follow it and embrace (but you are free to
+express your opinion that you don't agree with it).
+
+Here are a few rules that are important to keep in mind when you enter our community:
+
+ * Do not be afraid to ask questions
+ * We have deeply asynchronous communication - do not expect immediate answers, ping people if you are blocked
+ * We have #newbie-questions channel in slack as a safe place to ask questions
+ * You can ask one of the committers to be a mentor for you, they can guide within the community
+ * You can apply to more structured Apache Mentoring Programme
+ * It’s your responsibility as an author to take your PR from start-to-end including leading communication
+   in the PR
+ * It’s your responsibility as an author to ping committers to review your PR - be mildly annoying sometimes,
+   it’s OK to be slightly annoying with your change - it is also a sign for committers that you care
+ * We have high-bar set for the code requirements - be considerate to those requirements
 
 Review comment:
   Hm, maybe a short note why they are so high?

----------------------------------------------------------------
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.
 
For queries about this service, please contact Infrastructure at:
users@infra.apache.org


With regards,
Apache Git Services

[GitHub] [airflow] nuclearpinguin commented on a change in pull request #7204: [AIRFLOW-XXXX] - add communication chapter to contributing

Posted by GitBox <gi...@apache.org>.
nuclearpinguin commented on a change in pull request #7204: [AIRFLOW-XXXX] - add communication chapter to contributing
URL: https://github.com/apache/airflow/pull/7204#discussion_r368310976
 
 

 ##########
 File path: CONTRIBUTING.rst
 ##########
 @@ -664,6 +664,63 @@ Later on
    above depending if you have more commits that cause conflicts in your PR (rebasing applies each
    commit from your PR one-by-one).
 
+How to communicate
+==================
+
+Apache Airflow is a Community within Apache Software Foundation. As the motto of
+the Apache Software Foundation states "Community over Code" - people in the
+community are far more important than the code they create.
 
 Review comment:
   ```suggestion
   community are far more important than their contribution.
   ```
   As discussed during ACEU19, community needs more than just "code" 🚀

----------------------------------------------------------------
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.
 
For queries about this service, please contact Infrastructure at:
users@infra.apache.org


With regards,
Apache Git Services

[GitHub] [airflow] potiuk commented on a change in pull request #7204: [AIRFLOW-XXXX] - add communication chapter to contributing

Posted by GitBox <gi...@apache.org>.
potiuk commented on a change in pull request #7204: [AIRFLOW-XXXX] - add communication chapter to contributing
URL: https://github.com/apache/airflow/pull/7204#discussion_r368250461
 
 

 ##########
 File path: CONTRIBUTING.rst
 ##########
 @@ -567,6 +567,63 @@ Step 5: Pass PR Review
 Note that committers will use **Squash and Merge** instead of **Rebase and Merge**
 when merging PRs and your commit will be squashed to single commit.
 
+Communication
+=============
+
+Apache Airflow is a Community within Apache Software Foundation. As the motto of
+the Apache Software Foundation states "Community over Code" - people in the
+community are far more important than the code they create.
+
+This means that communication is very important, and this chapter is all about it.
+
+We have various channel of communication - starting from the official devlist, comments
+in the Pull Requests, Slack, wiki.
+
+All those channels can be used for different purposes:
+
+* The devlist for official communication, discussing proposals, voting, general issues, asking community for
+  opinion etc.
+* Wiki for detailed discussions on big proposals (AIPs) and some helpful, shared resources.
+* PRs for discussing implementation details of this PR (not for architectural discussions)
+* Slack for ad-hoc questions, troubleshooting, occassional discussions, group talks (including SIG - special
+interest groups), notifications, random queries, newbie questions etc.
+
+
+It is important to remember that all contributors, committers and even PMC members are individuals
+that contribute a lot of their free time on top of their work time to Apache Airflow.
+They have families, personal life, sometimes they are swamped with work, sometimes they are on vacations
+sometimes they are simply tired and need a time off. They are in various timezones and their responsiveness
+will vary from time to time. As a community project we have no formal structure, we have no managers nor
+departments and most of the people are autonomous in their opinions and decisions, so sometimes even
+committers will have different opinions on the same subjects.
+
+Disagreements are expected, discussions might include strong opinions and contradicting statements.
+Sometimes you might get two committers asking you to do things differently. This all happened in the past
+and will continue to happen. As a community we have some mechanisms to facilitate discussion and come to
+a consesus, conclusions and sometime we end up voting certain decisions. It is important that those
 
 Review comment:
   Thanks!

----------------------------------------------------------------
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.
 
For queries about this service, please contact Infrastructure at:
users@infra.apache.org


With regards,
Apache Git Services

[GitHub] [airflow] mschickensoup commented on a change in pull request #7204: [AIRFLOW-XXXX] - add communication chapter to contributing

Posted by GitBox <gi...@apache.org>.
mschickensoup commented on a change in pull request #7204: [AIRFLOW-XXXX] - add communication chapter to contributing
URL: https://github.com/apache/airflow/pull/7204#discussion_r369500411
 
 

 ##########
 File path: CONTRIBUTING.rst
 ##########
 @@ -664,6 +664,73 @@ Later on
    above depending if you have more commits that cause conflicts in your PR (rebasing applies each
    commit from your PR one-by-one).
 
+How to communicate
+==================
+
+Apache Airflow is a Community within Apache Software Foundation. As the motto of
+the Apache Software Foundation states "Community over Code" - people in the
+community are far more important than their contribution.
+
+This means that communication is very important, and this chapter is all about it.
+
+We have various channel of communication - starting from the official devlist, comments
+in the Pull Requests, Slack, wiki.
+
+All those channels can be used for different purposes:
+
+* The devlist for official communication, discussing proposals, voting, general issues, asking community for
+  opinion etc.
+* Wiki for detailed discussions on big proposals (AIPs) and some helpful, shared resources.
+* PRs for discussing implementation details of this PR (not for architectural discussions)
+* Slack for ad-hoc questions, troubleshooting, occassional discussions, group talks (including SIG - special
+interest groups), notifications, random queries, newbie questions etc.
 
 Review comment:
   [UI]
   
   I'm not sure how is it going to look in terms of the final UI but I'd use bullet points for each channel. Let's say it's "Wiki", so I'd describe the purpose of Wiki below in bullet points:
   
   - detailed discussions on big proposals (AIPs) 
   - helpful shared resources (what type of resources btw?) 
   
   Maybe it's not that useful in terms of description of the subject for Wiki but for Slack for sure. Let me know what you think. 
   
   [Content]
   
   **Devlist**
   If I were a beginner contributor I wouldn't know what actually dev-list is. What is lacking personally to me are the rules for communicating within the devlist itself. By this I mean that I don't know how I should compose the subject when I write about something and if I should add [DISCUSSION] / [AIP-XY] etc. It's a general comment that I'd also like to add to the Apache Airflow devlist. The reason I am not active within the devlist is my lack of knowledge on how to use it, so that everyone understands my point of view, the subject I touch is well-classified etc. 
   
   **Slack**
   
   How do I get an invitation to Slack? What is Slack? Some people might don't know. For most of you it sounds obvious but I'd be kind of lost. Speaking of China e.g. they have so different communication tools that I believe it might be worth to shortly describe Slack as a chat tool for ... _If you want to join Slack, ask XYZ for an invitation blah blah blah_
   
   Hope the above message is clear, what's your opinion? 

----------------------------------------------------------------
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.
 
For queries about this service, please contact Infrastructure at:
users@infra.apache.org


With regards,
Apache Git Services

[GitHub] [airflow] potiuk commented on a change in pull request #7204: [AIRFLOW-XXXX] - add communication chapter to contributing

Posted by GitBox <gi...@apache.org>.
potiuk commented on a change in pull request #7204: [AIRFLOW-XXXX] - add communication chapter to contributing
URL: https://github.com/apache/airflow/pull/7204#discussion_r380397903
 
 

 ##########
 File path: CONTRIBUTING.rst
 ##########
 @@ -664,6 +664,73 @@ Later on
    above depending if you have more commits that cause conflicts in your PR (rebasing applies each
    commit from your PR one-by-one).
 
+How to communicate
+==================
+
+Apache Airflow is a Community within Apache Software Foundation. As the motto of
+the Apache Software Foundation states "Community over Code" - people in the
+community are far more important than their contribution.
+
+This means that communication is very important, and this chapter is all about it.
+
+We have various channel of communication - starting from the official devlist, comments
+in the Pull Requests, Slack, wiki.
+
+All those channels can be used for different purposes:
+
+* The devlist for official communication, discussing proposals, voting, general issues, asking community for
+  opinion etc.
+* Wiki for detailed discussions on big proposals (AIPs) and some helpful, shared resources.
+* PRs for discussing implementation details of this PR (not for architectural discussions)
+* Slack for ad-hoc questions, troubleshooting, occassional discussions, group talks (including SIG - special
+interest groups), notifications, random queries, newbie questions etc.
+
+
+It is important to remember that all contributors, committers and even PMC members are individuals
+that contribute a lot of their free time on top of their work time to develop Apache Airflow.
+They have families, personal life, sometimes they are swamped with work, sometimes they are on vacations
+sometimes they are simply tired and need a time off. They are in various timezones and their responsiveness
+will vary from time to time. As a community project we have no formal structure, we have no managers nor
+departments and most of the people are autonomous in their opinions and decisions, so sometimes even
+committers will have different opinions on the same subjects.
+
+Disagreements are expected, discussions might include strong opinions and contradicting statements.
+Sometimes you might get two committers asking you to do things differently. This all happened in the past
+and will continue to happen. As a community we have some mechanisms to facilitate discussion and come to
+a consensus, conclusions and sometime we end up voting certain decisions. It is important that those
 
 Review comment:
   Done

----------------------------------------------------------------
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.
 
For queries about this service, please contact Infrastructure at:
users@infra.apache.org


With regards,
Apache Git Services

[GitHub] [airflow] nuclearpinguin commented on issue #7204: [AIRFLOW-XXXX] - add communication chapter to contributing

Posted by GitBox <gi...@apache.org>.
nuclearpinguin commented on issue #7204: [AIRFLOW-XXXX] - add communication chapter to contributing
URL: https://github.com/apache/airflow/pull/7204#issuecomment-576030124
 
 
   Hey @mschickensoup, would you like to take a look? 😺

----------------------------------------------------------------
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.
 
For queries about this service, please contact Infrastructure at:
users@infra.apache.org


With regards,
Apache Git Services

[GitHub] [airflow] potiuk commented on a change in pull request #7204: [AIRFLOW-XXXX] - add communication chapter to contributing

Posted by GitBox <gi...@apache.org>.
potiuk commented on a change in pull request #7204: [AIRFLOW-XXXX] - add communication chapter to contributing
URL: https://github.com/apache/airflow/pull/7204#discussion_r380398180
 
 

 ##########
 File path: CONTRIBUTING.rst
 ##########
 @@ -664,6 +664,73 @@ Later on
    above depending if you have more commits that cause conflicts in your PR (rebasing applies each
    commit from your PR one-by-one).
 
+How to communicate
+==================
+
+Apache Airflow is a Community within Apache Software Foundation. As the motto of
+the Apache Software Foundation states "Community over Code" - people in the
+community are far more important than their contribution.
+
+This means that communication is very important, and this chapter is all about it.
+
+We have various channel of communication - starting from the official devlist, comments
+in the Pull Requests, Slack, wiki.
+
+All those channels can be used for different purposes:
+
+* The devlist for official communication, discussing proposals, voting, general issues, asking community for
+  opinion etc.
+* Wiki for detailed discussions on big proposals (AIPs) and some helpful, shared resources.
+* PRs for discussing implementation details of this PR (not for architectural discussions)
+* Slack for ad-hoc questions, troubleshooting, occassional discussions, group talks (including SIG - special
+interest groups), notifications, random queries, newbie questions etc.
+
+
+It is important to remember that all contributors, committers and even PMC members are individuals
+that contribute a lot of their free time on top of their work time to develop Apache Airflow.
+They have families, personal life, sometimes they are swamped with work, sometimes they are on vacations
+sometimes they are simply tired and need a time off. They are in various timezones and their responsiveness
+will vary from time to time. As a community project we have no formal structure, we have no managers nor
+departments and most of the people are autonomous in their opinions and decisions, so sometimes even
+committers will have different opinions on the same subjects.
+
+Disagreements are expected, discussions might include strong opinions and contradicting statements.
+Sometimes you might get two committers asking you to do things differently. This all happened in the past
+and will continue to happen. As a community we have some mechanisms to facilitate discussion and come to
+a consensus, conclusions and sometime we end up voting certain decisions. It is important that those
+decisions are not treated as personal wins or looses. At the end it's the community that we all care about
+and what's good for community, should be accepted even if you have different opinion. There is the nice
+motto that you should follow in case you disagree with community decision "Disagree but engage". Even
+if you do not agree with a community decision, you should follow it and embrace (but you are free to
+express your opinion that you don't agree with it).
+
+As a community - we have high requirements for code quality. This is mainly because we are a distributed
+and loosely organised team - sometime we have contributors that commit one commit only, sometimes people add
+more commits, sometimes people assume informal "stewardship" over parts of code for some time - but at any
+time we should be sure that the code can be taken over by others - without excessive communication. Setting
 
 Review comment:
   Done

----------------------------------------------------------------
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.
 
For queries about this service, please contact Infrastructure at:
users@infra.apache.org


With regards,
Apache Git Services

[GitHub] [airflow] mschickensoup commented on a change in pull request #7204: [AIRFLOW-XXXX] - add communication chapter to contributing

Posted by GitBox <gi...@apache.org>.
mschickensoup commented on a change in pull request #7204: [AIRFLOW-XXXX] - add communication chapter to contributing
URL: https://github.com/apache/airflow/pull/7204#discussion_r369122288
 
 

 ##########
 File path: CONTRIBUTING.rst
 ##########
 @@ -664,6 +664,73 @@ Later on
    above depending if you have more commits that cause conflicts in your PR (rebasing applies each
    commit from your PR one-by-one).
 
+How to communicate
+==================
+
+Apache Airflow is a Community within Apache Software Foundation. As the motto of
+the Apache Software Foundation states "Community over Code" - people in the
+community are far more important than their contribution.
+
+This means that communication is very important, and this chapter is all about it.
+
+We have various channel of communication - starting from the official devlist, comments
+in the Pull Requests, Slack, wiki.
+
+All those channels can be used for different purposes:
+
+* The devlist for official communication, discussing proposals, voting, general issues, asking community for
+  opinion etc.
+* Wiki for detailed discussions on big proposals (AIPs) and some helpful, shared resources.
+* PRs for discussing implementation details of this PR (not for architectural discussions)
+* Slack for ad-hoc questions, troubleshooting, occassional discussions, group talks (including SIG - special
+interest groups), notifications, random queries, newbie questions etc.
+
+
+It is important to remember that all contributors, committers and even PMC members are individuals
 
 Review comment:
   even PMC members? I'd delete "even" :-) 

----------------------------------------------------------------
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.
 
For queries about this service, please contact Infrastructure at:
users@infra.apache.org


With regards,
Apache Git Services

[GitHub] [airflow] potiuk commented on a change in pull request #7204: [AIRFLOW-XXXX] - add communication chapter to contributing

Posted by GitBox <gi...@apache.org>.
potiuk commented on a change in pull request #7204: [AIRFLOW-XXXX] - add communication chapter to contributing
URL: https://github.com/apache/airflow/pull/7204#discussion_r380397085
 
 

 ##########
 File path: CONTRIBUTING.rst
 ##########
 @@ -664,6 +664,73 @@ Later on
    above depending if you have more commits that cause conflicts in your PR (rebasing applies each
    commit from your PR one-by-one).
 
+How to communicate
+==================
+
+Apache Airflow is a Community within Apache Software Foundation. As the motto of
+the Apache Software Foundation states "Community over Code" - people in the
+community are far more important than their contribution.
+
+This means that communication is very important, and this chapter is all about it.
+
+We have various channel of communication - starting from the official devlist, comments
+in the Pull Requests, Slack, wiki.
+
+All those channels can be used for different purposes:
+
+* The devlist for official communication, discussing proposals, voting, general issues, asking community for
+  opinion etc.
+* Wiki for detailed discussions on big proposals (AIPs) and some helpful, shared resources.
+* PRs for discussing implementation details of this PR (not for architectural discussions)
+* Slack for ad-hoc questions, troubleshooting, occassional discussions, group talks (including SIG - special
+interest groups), notifications, random queries, newbie questions etc.
+
+
+It is important to remember that all contributors, committers and even PMC members are individuals
+that contribute a lot of their free time on top of their work time to develop Apache Airflow.
+They have families, personal life, sometimes they are swamped with work, sometimes they are on vacations
+sometimes they are simply tired and need a time off. They are in various timezones and their responsiveness
+will vary from time to time. As a community project we have no formal structure, we have no managers nor
+departments and most of the people are autonomous in their opinions and decisions, so sometimes even
+committers will have different opinions on the same subjects.
+
+Disagreements are expected, discussions might include strong opinions and contradicting statements.
+Sometimes you might get two committers asking you to do things differently. This all happened in the past
+and will continue to happen. As a community we have some mechanisms to facilitate discussion and come to
+a consensus, conclusions and sometime we end up voting certain decisions. It is important that those
+decisions are not treated as personal wins or looses. At the end it's the community that we all care about
+and what's good for community, should be accepted even if you have different opinion. There is the nice
+motto that you should follow in case you disagree with community decision "Disagree but engage". Even
+if you do not agree with a community decision, you should follow it and embrace (but you are free to
+express your opinion that you don't agree with it).
+
+As a community - we have high requirements for code quality. This is mainly because we are a distributed
+and loosely organised team - sometime we have contributors that commit one commit only, sometimes people add
+more commits, sometimes people assume informal "stewardship" over parts of code for some time - but at any
+time we should be sure that the code can be taken over by others - without excessive communication. Setting
+high requirements for the code (fairly strict code review, static code checks, requirements of automated
+tests, pre-commit checks ) is the best way that we can achieve that - by only accepting good quality
+code with full test coverage we make sure that we can work with the code in the future.
+So do not be surprised if you are asked to add more tests or make the code cleaner -
+this is for the sake of maintainability.
+
+Here are a few rules that are important to keep in mind when you enter our community:
+
+ * Do not be afraid to ask questions
+ * The communication is asynchronous - do not expect immediate answers, ping others if you are blocked
 
 Review comment:
   added

----------------------------------------------------------------
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.
 
For queries about this service, please contact Infrastructure at:
users@infra.apache.org


With regards,
Apache Git Services

[GitHub] [airflow] mschickensoup commented on a change in pull request #7204: [AIRFLOW-XXXX] - add communication chapter to contributing

Posted by GitBox <gi...@apache.org>.
mschickensoup commented on a change in pull request #7204: [AIRFLOW-XXXX] - add communication chapter to contributing
URL: https://github.com/apache/airflow/pull/7204#discussion_r369505708
 
 

 ##########
 File path: CONTRIBUTING.rst
 ##########
 @@ -664,6 +664,73 @@ Later on
    above depending if you have more commits that cause conflicts in your PR (rebasing applies each
    commit from your PR one-by-one).
 
+How to communicate
+==================
+
+Apache Airflow is a Community within Apache Software Foundation. As the motto of
+the Apache Software Foundation states "Community over Code" - people in the
+community are far more important than their contribution.
+
+This means that communication is very important, and this chapter is all about it.
+
+We have various channel of communication - starting from the official devlist, comments
+in the Pull Requests, Slack, wiki.
+
+All those channels can be used for different purposes:
+
+* The devlist for official communication, discussing proposals, voting, general issues, asking community for
+  opinion etc.
+* Wiki for detailed discussions on big proposals (AIPs) and some helpful, shared resources.
+* PRs for discussing implementation details of this PR (not for architectural discussions)
+* Slack for ad-hoc questions, troubleshooting, occassional discussions, group talks (including SIG - special
+interest groups), notifications, random queries, newbie questions etc.
+
+
+It is important to remember that all contributors, committers and even PMC members are individuals
+that contribute a lot of their free time on top of their work time to develop Apache Airflow.
+They have families, personal life, sometimes they are swamped with work, sometimes they are on vacations
+sometimes they are simply tired and need a time off. They are in various timezones and their responsiveness
+will vary from time to time. As a community project we have no formal structure, we have no managers nor
+departments and most of the people are autonomous in their opinions and decisions, so sometimes even
+committers will have different opinions on the same subjects.
+
+Disagreements are expected, discussions might include strong opinions and contradicting statements.
+Sometimes you might get two committers asking you to do things differently. This all happened in the past
+and will continue to happen. As a community we have some mechanisms to facilitate discussion and come to
+a consensus, conclusions and sometime we end up voting certain decisions. It is important that those
+decisions are not treated as personal wins or looses. At the end it's the community that we all care about
+and what's good for community, should be accepted even if you have different opinion. There is the nice
+motto that you should follow in case you disagree with community decision "Disagree but engage". Even
+if you do not agree with a community decision, you should follow it and embrace (but you are free to
+express your opinion that you don't agree with it).
+
+As a community - we have high requirements for code quality. This is mainly because we are a distributed
+and loosely organised team - sometime we have contributors that commit one commit only, sometimes people add
+more commits, sometimes people assume informal "stewardship" over parts of code for some time - but at any
+time we should be sure that the code can be taken over by others - without excessive communication. Setting
+high requirements for the code (fairly strict code review, static code checks, requirements of automated
+tests, pre-commit checks ) is the best way that we can achieve that - by only accepting good quality
+code with full test coverage we make sure that we can work with the code in the future.
+So do not be surprised if you are asked to add more tests or make the code cleaner -
+this is for the sake of maintainability.
+
+Here are a few rules that are important to keep in mind when you enter our community:
+
+ * Do not be afraid to ask questions
+ * The communication is asynchronous - do not expect immediate answers, ping others if you are blocked
+ * There is a #newbie-questions channel in slack as a safe place to ask questions
+ * You can ask one of the committers to be a mentor for you, committers can guide within the community
 
 Review comment:
   ```suggestion
    * You can ask one of the committers to be a mentor for you, committers can guide you through the community
   ```

----------------------------------------------------------------
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.
 
For queries about this service, please contact Infrastructure at:
users@infra.apache.org


With regards,
Apache Git Services

[GitHub] [airflow] potiuk commented on a change in pull request #7204: [AIRFLOW-XXXX] - add communication chapter to contributing

Posted by GitBox <gi...@apache.org>.
potiuk commented on a change in pull request #7204: [AIRFLOW-XXXX] - add communication chapter to contributing
URL: https://github.com/apache/airflow/pull/7204#discussion_r368527661
 
 

 ##########
 File path: CONTRIBUTING.rst
 ##########
 @@ -664,6 +664,63 @@ Later on
    above depending if you have more commits that cause conflicts in your PR (rebasing applies each
    commit from your PR one-by-one).
 
+How to communicate
+==================
+
+Apache Airflow is a Community within Apache Software Foundation. As the motto of
+the Apache Software Foundation states "Community over Code" - people in the
+community are far more important than the code they create.
+
+This means that communication is very important, and this chapter is all about it.
+
+We have various channel of communication - starting from the official devlist, comments
+in the Pull Requests, Slack, wiki.
+
+All those channels can be used for different purposes:
+
+* The devlist for official communication, discussing proposals, voting, general issues, asking community for
+  opinion etc.
+* Wiki for detailed discussions on big proposals (AIPs) and some helpful, shared resources.
+* PRs for discussing implementation details of this PR (not for architectural discussions)
+* Slack for ad-hoc questions, troubleshooting, occassional discussions, group talks (including SIG - special
+interest groups), notifications, random queries, newbie questions etc.
+
+
+It is important to remember that all contributors, committers and even PMC members are individuals
+that contribute a lot of their free time on top of their work time to Apache Airflow.
+They have families, personal life, sometimes they are swamped with work, sometimes they are on vacations
 
 Review comment:
   Changed to "commiters" and reworded we in a few places.

----------------------------------------------------------------
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.
 
For queries about this service, please contact Infrastructure at:
users@infra.apache.org


With regards,
Apache Git Services

[GitHub] [airflow] mschickensoup commented on a change in pull request #7204: [AIRFLOW-XXXX] - add communication chapter to contributing

Posted by GitBox <gi...@apache.org>.
mschickensoup commented on a change in pull request #7204: [AIRFLOW-XXXX] - add communication chapter to contributing
URL: https://github.com/apache/airflow/pull/7204#discussion_r369505260
 
 

 ##########
 File path: CONTRIBUTING.rst
 ##########
 @@ -664,6 +664,73 @@ Later on
    above depending if you have more commits that cause conflicts in your PR (rebasing applies each
    commit from your PR one-by-one).
 
+How to communicate
+==================
+
+Apache Airflow is a Community within Apache Software Foundation. As the motto of
+the Apache Software Foundation states "Community over Code" - people in the
+community are far more important than their contribution.
+
+This means that communication is very important, and this chapter is all about it.
+
+We have various channel of communication - starting from the official devlist, comments
+in the Pull Requests, Slack, wiki.
+
+All those channels can be used for different purposes:
+
+* The devlist for official communication, discussing proposals, voting, general issues, asking community for
+  opinion etc.
+* Wiki for detailed discussions on big proposals (AIPs) and some helpful, shared resources.
+* PRs for discussing implementation details of this PR (not for architectural discussions)
+* Slack for ad-hoc questions, troubleshooting, occassional discussions, group talks (including SIG - special
+interest groups), notifications, random queries, newbie questions etc.
+
+
+It is important to remember that all contributors, committers and even PMC members are individuals
+that contribute a lot of their free time on top of their work time to develop Apache Airflow.
+They have families, personal life, sometimes they are swamped with work, sometimes they are on vacations
+sometimes they are simply tired and need a time off. They are in various timezones and their responsiveness
+will vary from time to time. As a community project we have no formal structure, we have no managers nor
+departments and most of the people are autonomous in their opinions and decisions, so sometimes even
+committers will have different opinions on the same subjects.
+
+Disagreements are expected, discussions might include strong opinions and contradicting statements.
+Sometimes you might get two committers asking you to do things differently. This all happened in the past
+and will continue to happen. As a community we have some mechanisms to facilitate discussion and come to
+a consensus, conclusions and sometime we end up voting certain decisions. It is important that those
+decisions are not treated as personal wins or looses. At the end it's the community that we all care about
+and what's good for community, should be accepted even if you have different opinion. There is the nice
+motto that you should follow in case you disagree with community decision "Disagree but engage". Even
+if you do not agree with a community decision, you should follow it and embrace (but you are free to
+express your opinion that you don't agree with it).
+
+As a community - we have high requirements for code quality. This is mainly because we are a distributed
+and loosely organised team - sometime we have contributors that commit one commit only, sometimes people add
+more commits, sometimes people assume informal "stewardship" over parts of code for some time - but at any
+time we should be sure that the code can be taken over by others - without excessive communication. Setting
+high requirements for the code (fairly strict code review, static code checks, requirements of automated
+tests, pre-commit checks ) is the best way that we can achieve that - by only accepting good quality
+code with full test coverage we make sure that we can work with the code in the future.
+So do not be surprised if you are asked to add more tests or make the code cleaner -
+this is for the sake of maintainability.
+
+Here are a few rules that are important to keep in mind when you enter our community:
+
+ * Do not be afraid to ask questions
+ * The communication is asynchronous - do not expect immediate answers, ping others if you are blocked
 
 Review comment:
   ```suggestion
    * The communication is asynchronous - do not expect immediate answers, ping others if you are blocked
   ```
   Where can I ping someone? Devlist / Slack? 

----------------------------------------------------------------
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.
 
For queries about this service, please contact Infrastructure at:
users@infra.apache.org


With regards,
Apache Git Services

[GitHub] [airflow] mschickensoup commented on a change in pull request #7204: [AIRFLOW-XXXX] - add communication chapter to contributing

Posted by GitBox <gi...@apache.org>.
mschickensoup commented on a change in pull request #7204: [AIRFLOW-XXXX] - add communication chapter to contributing
URL: https://github.com/apache/airflow/pull/7204#discussion_r369635061
 
 

 ##########
 File path: CONTRIBUTING.rst
 ##########
 @@ -664,6 +664,73 @@ Later on
    above depending if you have more commits that cause conflicts in your PR (rebasing applies each
    commit from your PR one-by-one).
 
+How to communicate
+==================
+
+Apache Airflow is a Community within Apache Software Foundation. As the motto of
+the Apache Software Foundation states "Community over Code" - people in the
+community are far more important than their contribution.
+
+This means that communication is very important, and this chapter is all about it.
+
+We have various channel of communication - starting from the official devlist, comments
+in the Pull Requests, Slack, wiki.
+
+All those channels can be used for different purposes:
+
+* The devlist for official communication, discussing proposals, voting, general issues, asking community for
+  opinion etc.
+* Wiki for detailed discussions on big proposals (AIPs) and some helpful, shared resources.
+* PRs for discussing implementation details of this PR (not for architectural discussions)
+* Slack for ad-hoc questions, troubleshooting, occassional discussions, group talks (including SIG - special
+interest groups), notifications, random queries, newbie questions etc.
+
+
+It is important to remember that all contributors, committers and even PMC members are individuals
+that contribute a lot of their free time on top of their work time to develop Apache Airflow.
+They have families, personal life, sometimes they are swamped with work, sometimes they are on vacations
+sometimes they are simply tired and need a time off. They are in various timezones and their responsiveness
+will vary from time to time. As a community project we have no formal structure, we have no managers nor
+departments and most of the people are autonomous in their opinions and decisions, so sometimes even
+committers will have different opinions on the same subjects.
+
+Disagreements are expected, discussions might include strong opinions and contradicting statements.
+Sometimes you might get two committers asking you to do things differently. This all happened in the past
+and will continue to happen. As a community we have some mechanisms to facilitate discussion and come to
+a consensus, conclusions and sometime we end up voting certain decisions. It is important that those
+decisions are not treated as personal wins or looses. At the end it's the community that we all care about
+and what's good for community, should be accepted even if you have different opinion. There is the nice
 
 Review comment:
   ```suggestion
   and what's good for community, should be accepted even if you have a different opinion. There is a nice
   ```

----------------------------------------------------------------
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.
 
For queries about this service, please contact Infrastructure at:
users@infra.apache.org


With regards,
Apache Git Services

[GitHub] [airflow] mschickensoup commented on a change in pull request #7204: [AIRFLOW-XXXX] - add communication chapter to contributing

Posted by GitBox <gi...@apache.org>.
mschickensoup commented on a change in pull request #7204: [AIRFLOW-XXXX] - add communication chapter to contributing
URL: https://github.com/apache/airflow/pull/7204#discussion_r369505507
 
 

 ##########
 File path: CONTRIBUTING.rst
 ##########
 @@ -664,6 +664,73 @@ Later on
    above depending if you have more commits that cause conflicts in your PR (rebasing applies each
    commit from your PR one-by-one).
 
+How to communicate
+==================
+
+Apache Airflow is a Community within Apache Software Foundation. As the motto of
+the Apache Software Foundation states "Community over Code" - people in the
+community are far more important than their contribution.
+
+This means that communication is very important, and this chapter is all about it.
+
+We have various channel of communication - starting from the official devlist, comments
+in the Pull Requests, Slack, wiki.
+
+All those channels can be used for different purposes:
+
+* The devlist for official communication, discussing proposals, voting, general issues, asking community for
+  opinion etc.
+* Wiki for detailed discussions on big proposals (AIPs) and some helpful, shared resources.
+* PRs for discussing implementation details of this PR (not for architectural discussions)
+* Slack for ad-hoc questions, troubleshooting, occassional discussions, group talks (including SIG - special
+interest groups), notifications, random queries, newbie questions etc.
+
+
+It is important to remember that all contributors, committers and even PMC members are individuals
+that contribute a lot of their free time on top of their work time to develop Apache Airflow.
+They have families, personal life, sometimes they are swamped with work, sometimes they are on vacations
+sometimes they are simply tired and need a time off. They are in various timezones and their responsiveness
+will vary from time to time. As a community project we have no formal structure, we have no managers nor
+departments and most of the people are autonomous in their opinions and decisions, so sometimes even
+committers will have different opinions on the same subjects.
+
+Disagreements are expected, discussions might include strong opinions and contradicting statements.
+Sometimes you might get two committers asking you to do things differently. This all happened in the past
+and will continue to happen. As a community we have some mechanisms to facilitate discussion and come to
+a consensus, conclusions and sometime we end up voting certain decisions. It is important that those
+decisions are not treated as personal wins or looses. At the end it's the community that we all care about
+and what's good for community, should be accepted even if you have different opinion. There is the nice
+motto that you should follow in case you disagree with community decision "Disagree but engage". Even
+if you do not agree with a community decision, you should follow it and embrace (but you are free to
+express your opinion that you don't agree with it).
+
+As a community - we have high requirements for code quality. This is mainly because we are a distributed
+and loosely organised team - sometime we have contributors that commit one commit only, sometimes people add
+more commits, sometimes people assume informal "stewardship" over parts of code for some time - but at any
+time we should be sure that the code can be taken over by others - without excessive communication. Setting
+high requirements for the code (fairly strict code review, static code checks, requirements of automated
+tests, pre-commit checks ) is the best way that we can achieve that - by only accepting good quality
+code with full test coverage we make sure that we can work with the code in the future.
+So do not be surprised if you are asked to add more tests or make the code cleaner -
+this is for the sake of maintainability.
+
+Here are a few rules that are important to keep in mind when you enter our community:
+
+ * Do not be afraid to ask questions
+ * The communication is asynchronous - do not expect immediate answers, ping others if you are blocked
+ * There is a #newbie-questions channel in slack as a safe place to ask questions
 
 Review comment:
   Ok, thanks 😄I think I'd mention this above when you write about Slack as a channel of communcation. 

----------------------------------------------------------------
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.
 
For queries about this service, please contact Infrastructure at:
users@infra.apache.org


With regards,
Apache Git Services

[GitHub] [airflow] potiuk commented on a change in pull request #7204: [AIRFLOW-XXXX] - add communication chapter to contributing

Posted by GitBox <gi...@apache.org>.
potiuk commented on a change in pull request #7204: [AIRFLOW-XXXX] - add communication chapter to contributing
URL: https://github.com/apache/airflow/pull/7204#discussion_r380397983
 
 

 ##########
 File path: CONTRIBUTING.rst
 ##########
 @@ -664,6 +664,73 @@ Later on
    above depending if you have more commits that cause conflicts in your PR (rebasing applies each
    commit from your PR one-by-one).
 
+How to communicate
+==================
+
+Apache Airflow is a Community within Apache Software Foundation. As the motto of
+the Apache Software Foundation states "Community over Code" - people in the
+community are far more important than their contribution.
+
+This means that communication is very important, and this chapter is all about it.
+
+We have various channel of communication - starting from the official devlist, comments
+in the Pull Requests, Slack, wiki.
+
+All those channels can be used for different purposes:
+
+* The devlist for official communication, discussing proposals, voting, general issues, asking community for
+  opinion etc.
+* Wiki for detailed discussions on big proposals (AIPs) and some helpful, shared resources.
+* PRs for discussing implementation details of this PR (not for architectural discussions)
+* Slack for ad-hoc questions, troubleshooting, occassional discussions, group talks (including SIG - special
+interest groups), notifications, random queries, newbie questions etc.
+
+
+It is important to remember that all contributors, committers and even PMC members are individuals
+that contribute a lot of their free time on top of their work time to develop Apache Airflow.
+They have families, personal life, sometimes they are swamped with work, sometimes they are on vacations
+sometimes they are simply tired and need a time off. They are in various timezones and their responsiveness
+will vary from time to time. As a community project we have no formal structure, we have no managers nor
+departments and most of the people are autonomous in their opinions and decisions, so sometimes even
+committers will have different opinions on the same subjects.
+
+Disagreements are expected, discussions might include strong opinions and contradicting statements.
+Sometimes you might get two committers asking you to do things differently. This all happened in the past
+and will continue to happen. As a community we have some mechanisms to facilitate discussion and come to
+a consensus, conclusions and sometime we end up voting certain decisions. It is important that those
+decisions are not treated as personal wins or looses. At the end it's the community that we all care about
+and what's good for community, should be accepted even if you have different opinion. There is the nice
+motto that you should follow in case you disagree with community decision "Disagree but engage". Even
+if you do not agree with a community decision, you should follow it and embrace (but you are free to
+express your opinion that you don't agree with it).
+
+As a community - we have high requirements for code quality. This is mainly because we are a distributed
+and loosely organised team - sometime we have contributors that commit one commit only, sometimes people add
 
 Review comment:
   Done

----------------------------------------------------------------
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.
 
For queries about this service, please contact Infrastructure at:
users@infra.apache.org


With regards,
Apache Git Services

[GitHub] [airflow] mschickensoup commented on a change in pull request #7204: [AIRFLOW-XXXX] - add communication chapter to contributing

Posted by GitBox <gi...@apache.org>.
mschickensoup commented on a change in pull request #7204: [AIRFLOW-XXXX] - add communication chapter to contributing
URL: https://github.com/apache/airflow/pull/7204#discussion_r369503819
 
 

 ##########
 File path: CONTRIBUTING.rst
 ##########
 @@ -664,6 +664,73 @@ Later on
    above depending if you have more commits that cause conflicts in your PR (rebasing applies each
    commit from your PR one-by-one).
 
+How to communicate
+==================
+
+Apache Airflow is a Community within Apache Software Foundation. As the motto of
+the Apache Software Foundation states "Community over Code" - people in the
+community are far more important than their contribution.
+
+This means that communication is very important, and this chapter is all about it.
+
+We have various channel of communication - starting from the official devlist, comments
+in the Pull Requests, Slack, wiki.
+
+All those channels can be used for different purposes:
+
+* The devlist for official communication, discussing proposals, voting, general issues, asking community for
+  opinion etc.
+* Wiki for detailed discussions on big proposals (AIPs) and some helpful, shared resources.
+* PRs for discussing implementation details of this PR (not for architectural discussions)
+* Slack for ad-hoc questions, troubleshooting, occassional discussions, group talks (including SIG - special
+interest groups), notifications, random queries, newbie questions etc.
+
+
+It is important to remember that all contributors, committers and even PMC members are individuals
+that contribute a lot of their free time on top of their work time to develop Apache Airflow.
+They have families, personal life, sometimes they are swamped with work, sometimes they are on vacations
+sometimes they are simply tired and need a time off. They are in various timezones and their responsiveness
+will vary from time to time. As a community project we have no formal structure, we have no managers nor
+departments and most of the people are autonomous in their opinions and decisions, so sometimes even
+committers will have different opinions on the same subjects.
 
 Review comment:
   See my comment from the above discussion. 

----------------------------------------------------------------
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.
 
For queries about this service, please contact Infrastructure at:
users@infra.apache.org


With regards,
Apache Git Services

[GitHub] [airflow] mschickensoup commented on a change in pull request #7204: [AIRFLOW-XXXX] - add communication chapter to contributing

Posted by GitBox <gi...@apache.org>.
mschickensoup commented on a change in pull request #7204: [AIRFLOW-XXXX] - add communication chapter to contributing
URL: https://github.com/apache/airflow/pull/7204#discussion_r369121587
 
 

 ##########
 File path: CONTRIBUTING.rst
 ##########
 @@ -664,6 +664,73 @@ Later on
    above depending if you have more commits that cause conflicts in your PR (rebasing applies each
    commit from your PR one-by-one).
 
+How to communicate
+==================
+
+Apache Airflow is a Community within Apache Software Foundation. As the motto of
+the Apache Software Foundation states "Community over Code" - people in the
+community are far more important than their contribution.
+
+This means that communication is very important, and this chapter is all about it.
+
+We have various channel of communication - starting from the official devlist, comments
 
 Review comment:
   ```suggestion
   We have various channel of communication - starting from the official devlist, comments
   ```
   We have various channels of communication - starting from the official devlist, 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.
 
For queries about this service, please contact Infrastructure at:
users@infra.apache.org


With regards,
Apache Git Services