aritra24 commented on code in PR #36969: URL: https://github.com/apache/airflow/pull/36969#discussion_r1464930407
########## README.md: ########## @@ -426,13 +427,23 @@ might decide to add additional limits (and justify them with comment). ## Contributing -Want to help build Apache Airflow? Check out our [contributing documentation](https://github.com/apache/airflow/blob/main/CONTRIBUTING.rst). +Want to help build Apache Airflow? Check out our [contributing documentation](https://github.com/apache/airflow/blob/main/contributing-docs/README.rst). Official Docker (container) images for Apache Airflow are described in [IMAGES.rst](https://github.com/apache/airflow/blob/main/IMAGES.rst). <!-- END Contributing, please keep comment here to allow auto update of PyPI readme.md --> <!-- START Who uses Apache Airflow, please keep comment here to allow auto update of PyPI readme.md --> +## Commit Policy + +The following commit policy passed by a vote 8(binding) FOR to 0 against on May 27, 2016 on the dev list Review Comment: by a vote of 8 (binding) FOR to 0 AGAINST* on... ########## README.md: ########## @@ -426,13 +427,23 @@ might decide to add additional limits (and justify them with comment). ## Contributing -Want to help build Apache Airflow? Check out our [contributing documentation](https://github.com/apache/airflow/blob/main/CONTRIBUTING.rst). +Want to help build Apache Airflow? Check out our [contributing documentation](https://github.com/apache/airflow/blob/main/contributing-docs/README.rst). Official Docker (container) images for Apache Airflow are described in [IMAGES.rst](https://github.com/apache/airflow/blob/main/IMAGES.rst). <!-- END Contributing, please keep comment here to allow auto update of PyPI readme.md --> <!-- START Who uses Apache Airflow, please keep comment here to allow auto update of PyPI readme.md --> +## Commit Policy + +The following commit policy passed by a vote 8(binding) FOR to 0 against on May 27, 2016 on the dev list +and slightly modified and consensus reached in October 2020: + +* Commits need a +1 vote from a committer who is not the author +* Do not merge a PR that regresses linting or does not pass CI tests (unless we have + justification such as clearly transient error). +* When we do AIP voting, both PMC and committer +1s are considered a binding vote. Review Comment: Probably also need to add the all conversations need to be resolved before merging ########## contributing-docs/02_how_to_communicate.rst: ########## @@ -0,0 +1,151 @@ + .. Licensed to the Apache Software Foundation (ASF) under one + or more contributor license agreements. See the NOTICE file + distributed with this work for additional information + regarding copyright ownership. The ASF licenses this file + to you under the Apache License, Version 2.0 (the + "License"); you may not use this file except in compliance + with the License. You may obtain a copy of the License at + + .. http://www.apache.org/licenses/LICENSE-2.0 + + .. Unless required by applicable law or agreed to in writing, + software distributed under the License is distributed on an + "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY + KIND, either express or implied. See the License for the + specific language governing permissions and limitations + under the License. + +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 plays a big role in it, and this chapter is all about it. + +In our communication, everyone is expected to follow the `ASF Code of Conduct <https://www.apache.org/foundation/policies/conduct>`_. + +.. contents:: :local: + +Various Communication channels +------------------------------ + +We have various channels of communication - starting from the official devlist, comments +in the PR, Slack, wiki. + +All those channels can be used for different purposes. +You can join the channels via links at the `Airflow Community page <https://airflow.apache.org/community/>`_ + +* The `Apache Airflow devlist <https://lists.apache.org/list.html?d...@airflow.apache.org>`_ for: + * official communication + * general issues, asking community for opinion + * discussing proposals + * voting +* The `Airflow CWiki <https://cwiki.apache.org/confluence/display/AIRFLOW/Airflow+Home?src=breadcrumbs>`_ for: + * detailed discussions on big proposals (Airflow Improvement Proposals also name AIPs) + * helpful, shared resources (for example Apache Airflow logos + * information that can be reused by others (for example instructions on preparing workshops) +* GitHub `Pull Requests (PRs) <https://github.com/apache/airflow/pulls>`_ for: + * discussing implementation details of PRs + * not for architectural discussions (use the devlist for that) +* The deprecated `JIRA issues <https://issues.apache.org/jira/projects/AIRFLOW/issues/AIRFLOW-4470?filter=allopenissues>`_ for: + * checking out old but still valuable issues that are not on GitHub yet + * mentioning the JIRA issue number in the title of the related PR you would like to open on GitHub + +**IMPORTANT** +We don't create new issues on JIRA anymore. The reason we still look at JIRA issues is that there are valuable +tickets inside of it. However, each new PR should be created on `GitHub issues <https://github.com/apache/airflow/issues>`_ +as stated in `Contribution Workflow Example <contribution-workflow.rst>`_ + +Slack details +------------- + +* The `Apache Airflow Slack <https://s.apache.org/airflow-slack>`_ for: + * ad-hoc questions related to development (#development channel) + * asking for review (#development channel) + * asking for help with first contribution PRs (#development-first-pr-support channel) + * troubleshooting (#troubleshooting channel) + * group talks (including SIG - special interest groups) (#sig-* channels) + * notifications (#announcements channel) + * random queries (#random channel) + * regional announcements (#users-* channels) + * occasional discussions (wherever appropriate including group and 1-1 discussions) + +Please exercise caution against posting same questions across multiple channels. Doing so not only prevents +redundancy but also promotes more efficient and effective communication for everyone involved. + +Devlist details +--------------- + +The devlist is the most important and official communication channel. Often at Apache project you can +hear "if it is not in the devlist - it did not happen". If you discuss and agree with someone from the +community on something important for the community (including if it is with maintainer or PMC member) the +discussion must be captured and reshared on devlist in order to give other members of the community to +participate in it. + +We are using certain prefixes for email subjects for different purposes. Start your email with one of those: + * ``[DISCUSS]`` - if you want to discuss something but you have no concrete proposal yet + * ``[PROPOSAL]`` - if usually after "[DISCUSS]" thread discussion you want to propose something and see + what other members of the community think about it. + * ``[AIP-NN]`` - if the mail is about one of the Airflow Improvement Proposals + * ``[VOTE]`` - if you would like to start voting on a proposal discussed before in a "[PROPOSAL]" thread + +Voting is governed by the rules described in `Voting <https://www.apache.org/foundation/voting.html>`_ + +What to expect from the community +--------------------------------- + +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 timezones or simply are +busy 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. + +Disagreements are expected, discussions might include strong opinions and contradicting statements. +Sometimes you might get two maintainers 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 or we end up voting to make important decisions. It is important that these +decisions are not treated as personal wins or looses. At the end it's the community that we all care about Review Comment: Wins or losses* ########## contributing-docs/01_roles_in_airflow_project.rst: ########## @@ -0,0 +1,177 @@ + .. Licensed to the Apache Software Foundation (ASF) under one + or more contributor license agreements. See the NOTICE file + distributed with this work for additional information + regarding copyright ownership. The ASF licenses this file + to you under the Apache License, Version 2.0 (the + "License"); you may not use this file except in compliance + with the License. You may obtain a copy of the License at + + .. http://www.apache.org/licenses/LICENSE-2.0 + + .. Unless required by applicable law or agreed to in writing, + software distributed under the License is distributed on an + "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY + KIND, either express or implied. See the License for the + specific language governing permissions and limitations + under the License. + +Roles in Airflow project +======================== + +There are several roles within the Airflow Open-Source community. + +For detailed information for each role, see: `Committers and PMC members <../COMMITTERS.rst>`__. + +.. contents:: :local: + +PMC Member +---------- + +The PMC (Project Management Committee) is a group of maintainers that drives changes in the way that +Airflow is managed as a project. + +Considering Apache, the role of the PMC is primarily to ensure that Airflow conforms to Apache's processes +and guidelines. + +Committers/Maintainers +---------------------- + +You will often see the term "committer" or "maintainer" in the context of the Airflow project. This is a person +who has write access to the Airflow repository and can merge pull requests. Committers (also known as maintainers) +are also responsible for reviewing pull requests and guiding contributors to make their first contribution. +They are also responsible for making sure that the project is moving forward and that the quality of the +code is maintained. + +The term "committer" and "maintainer" is used interchangeably. The term "committer" is the official term used by the +Apache Software Foundation, while "maintainer" is more commonly used in the Open Source community and is used +in context of GitHub in a number of guidelines and documentation, so this document will mostly use "maintainer", +when speaking about Github, Pull Request, Github Issues and Discussions. On the other hand, "committer" is more +often used in devlist discussions, official communications, Airflow website and every time when we formally +refer to the role. + +The official list of committers can be found `here <https://airflow.apache.org/docs/apache-airflow/stable/project.html#committers>`__. + +Additionally, committers are listed in a few other places (some of these may only be visible to existing committers): + +* https://whimsy.apache.org/roster/committee/airflow +* https://github.com/orgs/apache/teams/airflow-committers/members + +Committers are responsible for: + +* Championing one or more items on the `Roadmap <https://cwiki.apache.org/confluence/display/AIRFLOW/Airflow+Home>`__ +* Reviewing & Merging Pull-Requests +* Scanning and responding to GitHub issues +* Responding to questions on the dev mailing list (d...@airflow.apache.org) + +Release managers +---------------- + +The task of release managers is to prepare and release Airflow artifacts (airflow, providers, Helm Chart, Python client. +The release managers are usually PMC members and the process of releasing is described in the `dev <dev>`__ +documentation where we keep information and tools used for releasing. + +Contributors +------------ + +A contributor is anyone who wants to contribute code, documentation, tests, ideas, or anything to the +Apache Airflow project. + +Contributors are responsible for: + +* Fixing bugs +* Adding features +* Championing one or more items on the `Roadmap <https://cwiki.apache.org/confluence/display/AIRFLOW/Airflow+Home>`__. + +Security Team +------------- + +Security issues in Airflow are handled by the Airflow Security Team. The team consists +of selected PMC members that are interested in looking at, discussing and fixing +security issues, but it can also include committers and non-committer contributors that are +not PMC members yet and have been approved by the PMC members in a vote. You can request to +be added to the team by sending a message to priv...@airflow.apache.org. However, the team +should be small and focused on solving security issues, so the requests will be evaluated +on a case-by-case basis and the team size will be kept relatively small, limited to only actively +security-focused contributors. + +There are certain expectations from the members of the security team: + +* They are supposed to be active in assessing, discussing, fixing and releasing the + security issues in Airflow. While it is perfectly understood that as volunteers, we might have + periods of lower activity, prolonged lack of activity and participation will result in removal + from the team, pending PMC decision (the decision on removal can be taken by `LAZY CONSENSUS <https://community.apache.org/committers/lazyConsensus.html>`_ among + all the PMC members on priv...@airflow.apache.org mailing list). + +* They are not supposed to reveal the information about pending and unfixed security issues to anyone + (including their employers) unless specifically authorised by the security team members, specifically + if diagnosing and solving the issue might involve the need of external experts - for example security + experts that are available through Airflow stakeholders. The intent about involving 3rd parties has + to be discussed and agreed upon at secur...@airflow.apache.org. + +* They have to have an `ICLA <https://www.apache.org/licenses/contributor-agreements.html>`_ signed with + Apache Software Foundation. + +* The security team members might inform 3rd parties about fixes, for example in order to assess if the fix + is solving the problem or in order to assess its applicability to be applied by 3rd parties, as soon + as a PR solving the issue is opened in the public airflow repository. + +* In case of critical security issues, the members of the security team might iterate on a fix in a + private repository and only open the PR in the public repository once the fix is ready to be released, + with the intent of minimizing the time between the fix being available and the fix being released. In this + case the PR might be sent to review and comment to the PMC members on private list, in order to request + an expedited voting on the release. The voting for such release might be done on the + priv...@airflow.apache.org mailing list and should be made public at the d...@apache.airflow.org + mailing list as soon as the release is ready to be announced. + +* The security team members working on the fix might be mentioned as remediation developers in the CVE + including their job affiliation if they want to. + +* Community members acting as release managers are by default members of the security team and unless they + want to, they do not have to be involved in discussing and solving the issues. They are responsible for + releasing the CVE information (announcement and publishing to security indexes) as part of the + release process. This is facilitated by the security tool provided by the Apache Software Foundation. + +* Severity of the issue is determined based on the criteria described in the + `Severity Rating blog post <https://security.apache.org/blog/severityrating/>`_ by the Apache Software + Foundation Security team. + +Handling security issues is something of a chore, it takes vigilance, requires quick reaction and responses +and often requires to act outside of the regular "day" job. This means that not everyone can keep up with +being part of the security team for long while being engaged and active. While we do not expect all the +security team members to be active all the time, and - since we are volunteers, it's perfectly understandable +that work, personal life, family and generally life might not help with being active. And this is not a +considered as being failure, it's more stating the fact of life. + +Also prolonged time of being exposed to handling "other's" problems and discussing similar kinds of problem +and responses might be tiring and might lead to burnout. + +However, for those who have never done that before, participation in the security team might be an interesting +experience and a way to learn a lot about security and security issue handling. We have a lot of +established processes and tools that make the work of the security team members easier, so this can be +treated as a great learning experience for some community members. And knowing that this is not +a "lifetime" assignment, but rather a temporary engagement might make it easier for people to decide to +join the security team. + +That's why introduced rotation of the security team members. Review Comment: That's why we've* introduced rotation of... ########## contributing-docs/02_how_to_communicate.rst: ########## @@ -0,0 +1,151 @@ + .. Licensed to the Apache Software Foundation (ASF) under one + or more contributor license agreements. See the NOTICE file + distributed with this work for additional information + regarding copyright ownership. The ASF licenses this file + to you under the Apache License, Version 2.0 (the + "License"); you may not use this file except in compliance + with the License. You may obtain a copy of the License at + + .. http://www.apache.org/licenses/LICENSE-2.0 + + .. Unless required by applicable law or agreed to in writing, + software distributed under the License is distributed on an + "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY + KIND, either express or implied. See the License for the + specific language governing permissions and limitations + under the License. + +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 plays a big role in it, and this chapter is all about it. + +In our communication, everyone is expected to follow the `ASF Code of Conduct <https://www.apache.org/foundation/policies/conduct>`_. + +.. contents:: :local: + +Various Communication channels +------------------------------ + +We have various channels of communication - starting from the official devlist, comments +in the PR, Slack, wiki. + +All those channels can be used for different purposes. +You can join the channels via links at the `Airflow Community page <https://airflow.apache.org/community/>`_ + +* The `Apache Airflow devlist <https://lists.apache.org/list.html?d...@airflow.apache.org>`_ for: + * official communication + * general issues, asking community for opinion + * discussing proposals + * voting +* The `Airflow CWiki <https://cwiki.apache.org/confluence/display/AIRFLOW/Airflow+Home?src=breadcrumbs>`_ for: + * detailed discussions on big proposals (Airflow Improvement Proposals also name AIPs) + * helpful, shared resources (for example Apache Airflow logos + * information that can be reused by others (for example instructions on preparing workshops) +* GitHub `Pull Requests (PRs) <https://github.com/apache/airflow/pulls>`_ for: + * discussing implementation details of PRs + * not for architectural discussions (use the devlist for that) +* The deprecated `JIRA issues <https://issues.apache.org/jira/projects/AIRFLOW/issues/AIRFLOW-4470?filter=allopenissues>`_ for: + * checking out old but still valuable issues that are not on GitHub yet + * mentioning the JIRA issue number in the title of the related PR you would like to open on GitHub + +**IMPORTANT** +We don't create new issues on JIRA anymore. The reason we still look at JIRA issues is that there are valuable +tickets inside of it. However, each new PR should be created on `GitHub issues <https://github.com/apache/airflow/issues>`_ +as stated in `Contribution Workflow Example <contribution-workflow.rst>`_ + +Slack details +------------- + +* The `Apache Airflow Slack <https://s.apache.org/airflow-slack>`_ for: + * ad-hoc questions related to development (#development channel) + * asking for review (#development channel) + * asking for help with first contribution PRs (#development-first-pr-support channel) + * troubleshooting (#troubleshooting channel) + * group talks (including SIG - special interest groups) (#sig-* channels) + * notifications (#announcements channel) + * random queries (#random channel) + * regional announcements (#users-* channels) + * occasional discussions (wherever appropriate including group and 1-1 discussions) + +Please exercise caution against posting same questions across multiple channels. Doing so not only prevents +redundancy but also promotes more efficient and effective communication for everyone involved. + +Devlist details +--------------- + +The devlist is the most important and official communication channel. Often at Apache project you can +hear "if it is not in the devlist - it did not happen". If you discuss and agree with someone from the +community on something important for the community (including if it is with maintainer or PMC member) the +discussion must be captured and reshared on devlist in order to give other members of the community to +participate in it. + +We are using certain prefixes for email subjects for different purposes. Start your email with one of those: + * ``[DISCUSS]`` - if you want to discuss something but you have no concrete proposal yet + * ``[PROPOSAL]`` - if usually after "[DISCUSS]" thread discussion you want to propose something and see + what other members of the community think about it. + * ``[AIP-NN]`` - if the mail is about one of the Airflow Improvement Proposals + * ``[VOTE]`` - if you would like to start voting on a proposal discussed before in a "[PROPOSAL]" thread + +Voting is governed by the rules described in `Voting <https://www.apache.org/foundation/voting.html>`_ + +What to expect from the community +--------------------------------- + +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 timezones or simply are +busy 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. Review Comment: most of us are* autonomous -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: commits-unsubscr...@airflow.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
