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:
us...@infra.apache.org


With regards,
Apache Git Services

Reply via email to