| .. 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 (dev@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 private@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 private@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 authorized 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 security@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 |
| private@airflow.apache.org mailing list and should be made public at the dev@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 we've introduced rotation of the security team members. |
| |
| Periodically - every 3-4 months (depending on actual churn of the security issues that are reported to us), |
| we re-evaluate the engagement and activity of the security team members, and we ask them if they want to |
| continue being part of the security team, taking into account their engagement since the last team refinement. |
| Generally speaking if the engagement during the last period was marginal, the person is considered as a |
| candidate for removing from the team and it requires a deliberate confirmation of re-engagement to take |
| the person off-the-list. |
| |
| At the same time we open up the possibility to other people in the community to join the team and make |
| a "call for new security team members" where community members can volunteer to join the security team. |
| Such volunteering should happen on the private@ list. The current members of the security team as well |
| as PMC members can also nominate other community members to join the team and those new team members |
| have to be well recognized and trusted by the community and accepted by the PMC. |
| |
| The proposal of team refinement is passed to the PMC as LAZY CONSENSUS (or VOTE if consensus cannot |
| be reached). In case the consensus cannot be reached for the whole list, we can split it and ask for |
| lazy consensus for each person separately. |
| |
| ------------- |
| |
| You can follow this with the `How to communicate <02_how_to_communicate.rst>`__ document to learn more how |
| to communicate with the Airflow community members. |