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 2021/02/14 03:00:14 UTC
[GitHub] [airflow] vikramkoka opened a new pull request #14223: Added Issue reporting and triage process document
vikramkoka opened a new pull request #14223:
URL: https://github.com/apache/airflow/pull/14223
Added Issue reporting and triage process document, including the
updated set of labels to be used for reporting and tracking issues.
---
**^ Add meaningful description above**
Read the **[Pull Request Guidelines](https://github.com/apache/airflow/blob/master/CONTRIBUTING.rst#pull-request-guidelines)** for more information.
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).
----------------------------------------------------------------
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
[GitHub] [airflow] eladkal commented on a change in pull request #14223: Added Issue reporting and triage process document
Posted by GitBox <gi...@apache.org>.
eladkal commented on a change in pull request #14223:
URL: https://github.com/apache/airflow/pull/14223#discussion_r577759700
##########
File path: docs/apache-airflow/issue-triage-process.rst
##########
@@ -0,0 +1,195 @@
+ .. 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.
+
+
+
+
+Issue reporting and resolution process
+======================================
+
+This document explains the issue tracking and triage process within Apache
+Airflow including labels, milestones, and priorities as well as the process
+of resolving issues.
+
+Labels
+''''''
+
+Since Apache Airflow uses Github Issues as the issue tracking system, the
+use of labels is extensive. Though issue labels tend to change over time
+based on components within the project, the majority of the ones listed
+below should stand the test of time.
+
+The intention with the use of labels with the Apache Airflow project is
+that they should ideally be non-temporal in nature and primarily used
+to indicate the following elements:
+
+**Kind**
+
+The “kind” labels indicate “what kind of issue it is”. The most
+commonly used “kind” labels are: bug, feature, documentation, or task.
+
+Therefore, when reporting an issue, the label of ``kind:bug`` is to
+indicate a problem with the functionality, whereas the label of
+``kind:feature`` is a desire to extend the functionality.
+
+There has been discussion within the project about whether to separate
+the desire for “new features” from “enhancements to existing features”,
+but in practice most “feature requests” are actually enhancement requests,
+so we decided to combine them both into ``kind:feature``.
+
+We recently introduced ``kind:task`` to categorize issues which are
Review comment:
```suggestion
The ``kind:task`` is used to categorize issues which are
```
i'm not sure if it matters that this was recently added? Also, saves the future issue of fixing the sentence when "recently" is not true any longer.
##########
File path: docs/apache-airflow/issue-triage-process.rst
##########
@@ -0,0 +1,195 @@
+ .. 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.
+
+
+
+
+Issue reporting and resolution process
+======================================
+
+This document explains the issue tracking and triage process within Apache
+Airflow including labels, milestones, and priorities as well as the process
+of resolving issues.
+
+Labels
+''''''
+
+Since Apache Airflow uses Github Issues as the issue tracking system, the
+use of labels is extensive. Though issue labels tend to change over time
+based on components within the project, the majority of the ones listed
+below should stand the test of time.
+
+The intention with the use of labels with the Apache Airflow project is
+that they should ideally be non-temporal in nature and primarily used
+to indicate the following elements:
+
+**Kind**
+
+The “kind” labels indicate “what kind of issue it is”. The most
+commonly used “kind” labels are: bug, feature, documentation, or task.
+
+Therefore, when reporting an issue, the label of ``kind:bug`` is to
+indicate a problem with the functionality, whereas the label of
+``kind:feature`` is a desire to extend the functionality.
+
+There has been discussion within the project about whether to separate
+the desire for “new features” from “enhancements to existing features”,
+but in practice most “feature requests” are actually enhancement requests,
+so we decided to combine them both into ``kind:feature``.
+
+We recently introduced ``kind:task`` to categorize issues which are
+identified elements of work to be done, primarily as part of a larger
+change to be done as part of an AIP or something which needs to be cleaned
+up in the project.
+
+Issues of ``kind:documentation`` are for changes which need to be
+made to the documentation within the project.
+
+
+**Area**
+
+The “area” set of labels should indicate the component of the code
+referenced by the issue. At a high level, the biggest areas of the project
+are: Airflow Core and Airflow Providers, which are referenced by ``area:core``
+and ``area:providers``. This is especially important since these are now
+being released and versioned independently.
+
+There are more detailed areas of the project such as Scheduler, Webserver,
+API, UI, Logging, and Kubernetes, which are all conceptually under the
+“Airflow Core” area of the project.
+
+Similarly, some providers are broken out such as Apache (``provider/Apache``),
Review comment:
Is broken out the proper way to describe it? I'm not native English speaker but this sounds a bit odd to me. Maybe split / divide are more suitable?
##########
File path: docs/apache-airflow/issue-triage-process.rst
##########
@@ -0,0 +1,195 @@
+ .. 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.
+
+
+
+
+Issue reporting and resolution process
+======================================
+
+This document explains the issue tracking and triage process within Apache
+Airflow including labels, milestones, and priorities as well as the process
+of resolving issues.
Review comment:
Should we mention here that there is no need to open an issue prior to opening a PR?
##########
File path: docs/apache-airflow/issue-triage-process.rst
##########
@@ -0,0 +1,195 @@
+ .. 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.
+
+
+
+
+Issue reporting and resolution process
+======================================
+
+This document explains the issue tracking and triage process within Apache
+Airflow including labels, milestones, and priorities as well as the process
+of resolving issues.
+
+Labels
+''''''
+
+Since Apache Airflow uses Github Issues as the issue tracking system, the
+use of labels is extensive. Though issue labels tend to change over time
+based on components within the project, the majority of the ones listed
+below should stand the test of time.
+
+The intention with the use of labels with the Apache Airflow project is
+that they should ideally be non-temporal in nature and primarily used
+to indicate the following elements:
+
+**Kind**
+
+The “kind” labels indicate “what kind of issue it is”. The most
+commonly used “kind” labels are: bug, feature, documentation, or task.
+
+Therefore, when reporting an issue, the label of ``kind:bug`` is to
+indicate a problem with the functionality, whereas the label of
+``kind:feature`` is a desire to extend the functionality.
+
+There has been discussion within the project about whether to separate
+the desire for “new features” from “enhancements to existing features”,
+but in practice most “feature requests” are actually enhancement requests,
+so we decided to combine them both into ``kind:feature``.
+
+We recently introduced ``kind:task`` to categorize issues which are
+identified elements of work to be done, primarily as part of a larger
+change to be done as part of an AIP or something which needs to be cleaned
+up in the project.
+
+Issues of ``kind:documentation`` are for changes which need to be
+made to the documentation within the project.
+
+
+**Area**
+
+The “area” set of labels should indicate the component of the code
+referenced by the issue. At a high level, the biggest areas of the project
+are: Airflow Core and Airflow Providers, which are referenced by ``area:core``
+and ``area:providers``. This is especially important since these are now
+being released and versioned independently.
+
+There are more detailed areas of the project such as Scheduler, Webserver,
+API, UI, Logging, and Kubernetes, which are all conceptually under the
+“Airflow Core” area of the project.
+
+Similarly, some providers are broken out such as Apache (``provider/Apache``),
+AWS (``provider/AWS``), Azure (``provider/Azure``), and Google (``provider/Google``).
+These make it easier for developers working on a single provider to
+track issues for that provider.
+
+Most issues need a combination of "kind" and "area" labels to be actionable.
+For example:
+
+* Feature request for an additional API would have ``kind:feature`` and ``area:API``
+* Bug report on the User Interface would have ``kind:bug`` and ``area:UI``
+* Documentation request on the Kubernetes Executor, would have ``kind:documentation`` and ``area:kubernetes``
+
+
+Response to issues
+''''''''''''''''''
+
+Once an issue has been created on the Airflow project, someone from the
+Airflow team or the Airflow community typically responds to this issue.
+This response can have multiple elements.
+
+**Priority**
+
+After significant discussion about the different priority schemes currently
+being used across various projects, we decided to use a priority scheme based
+on the Kubernetes project, since the team felt it was easier for people to
+understand.
+
+Therefore, the priority labels used are:
+
+* ``priority:critical``: Showstopper bug that should be resolved immediately and a patch issued as soon as possible. Typically, this is because it affects most users and would take down production systems.
+* ``priority:high``: A high priority bug that affects many users and should be resolved quickly, but can wait for the next scheduled patch release.
+* ``priority:medium``: A bug that should be fixed before the next release, but would not block a release if found during the release process.
+* ``priority:low``: A bug with a simple workaround or a nuisance that does not stop mainstream functionality.
+
+
+It's important to use priority labels effectively so we can triage incoming issues
+appropriately and make sure that when we release a new version of Airflow,
+we can ship a release confident that there are no “production blocker” issues in it.
+
+
+**Milestones**
+
+The key temporal element in the issue triage process is the concept of milestones.
+This is critical for release management purposes and will be used represent upcoming
+release targets.
+
+Issues currently being resolved will get assigned to one of the upcoming releases.
+For example a feature request may be targeted for the next feature release milestone
+such as ``2.x``, where a bug may be targeted for the next patch release milestone
+such as ``2.x.y``.
+
+In the interest of being precise, when an issue is tagged with a milestone, it
+represents that it will be considered for that release, not that it is committed to
+a release. Once a PR is created to fix that issue and when that PR is tagged with a
+milestone, it implies that the PR is intended to released in that milestone.
+
+It is worth noting that Airflow Core and Airflow Providers are now released and
+versioned separately, so they may have a different set of milestones.
+
+
+**Transient Labels**
+
+Sometimes, there is more information needed to either understand the issue or
+to be able to reproduce the issue. Typically, this may require a response to the
+issue creator asking for more information, with the issue then being tagged with
+the label ``pending-response``.
+Also, during this stage, additional labels may be added to the issue to help
+classification and triage, such as ``reported_version`` and ``area``.
+
+Occasionally an issue may require a larger discussion among the Airflow PMC or
+the developer mailing list. This issue may then be tagged with the
+``needs:discussion`` label.
+
+Some issues may need a detailed review by one of the core committers of the project
+and this could be tagged with a ``needs:triage`` label.
+
+
+**Good First Issue**
+
+Issues which are relatively straight forward to solve, will be tagged with
+the ``GoodFirstIssue`` label.
+
+The intention here is to galvanize contributions from new and inexperienced
+contributors who are looking to contribute to the project. This has been successful
+in other open source projects and early signs are that this has been helpful in the
+Airflow project as well.
+
+Ideally, these issues only require one or two files to be changed. The intention
+here is that incremental changes to existing files are a lot easier for a new
+contributor as compared to adding something completely new.
+
+Another possibility here is to add “how to fix” in the comments of such issues, so
+that new contributors have a running start when then pick up these issues.
+
+
+**Timeliness**
+
+For the sake of quick responses, the general “soft" rule within the Airflow project
+is that if there is no assignee, anyone can take an issue to solve.
+
+However, this depends on timely resolution of the issue by the assignee. The
+expectation is as follows:
+
+* If there is no activity on the issue for 2 weeks, the assignee will be reminded about the issue and asked if they are still working on it.
+* If there is no activity even after 1 more week, the issue will be unassigned, so that someone else can pick it up and work on it.
+
+
+There is a similar process when additional information is requested from the
+issue creator. After the pending-response label has been assigned, if there is no
+further information for a period of 1 month, the issue will be automatically closed.
+
+
+
+**Invalidity**
Review comment:
we should also add note about `won't fix`
##########
File path: docs/apache-airflow/issue-triage-process.rst
##########
@@ -0,0 +1,195 @@
+ .. 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.
+
+
+
+
+Issue reporting and resolution process
+======================================
+
+This document explains the issue tracking and triage process within Apache
+Airflow including labels, milestones, and priorities as well as the process
+of resolving issues.
+
+Labels
+''''''
+
+Since Apache Airflow uses Github Issues as the issue tracking system, the
+use of labels is extensive. Though issue labels tend to change over time
+based on components within the project, the majority of the ones listed
+below should stand the test of time.
+
+The intention with the use of labels with the Apache Airflow project is
+that they should ideally be non-temporal in nature and primarily used
+to indicate the following elements:
+
+**Kind**
+
+The “kind” labels indicate “what kind of issue it is”. The most
+commonly used “kind” labels are: bug, feature, documentation, or task.
+
+Therefore, when reporting an issue, the label of ``kind:bug`` is to
+indicate a problem with the functionality, whereas the label of
+``kind:feature`` is a desire to extend the functionality.
+
+There has been discussion within the project about whether to separate
+the desire for “new features” from “enhancements to existing features”,
+but in practice most “feature requests” are actually enhancement requests,
+so we decided to combine them both into ``kind:feature``.
+
+We recently introduced ``kind:task`` to categorize issues which are
+identified elements of work to be done, primarily as part of a larger
+change to be done as part of an AIP or something which needs to be cleaned
+up in the project.
+
+Issues of ``kind:documentation`` are for changes which need to be
+made to the documentation within the project.
+
+
+**Area**
+
+The “area” set of labels should indicate the component of the code
+referenced by the issue. At a high level, the biggest areas of the project
+are: Airflow Core and Airflow Providers, which are referenced by ``area:core``
+and ``area:providers``. This is especially important since these are now
+being released and versioned independently.
+
+There are more detailed areas of the project such as Scheduler, Webserver,
+API, UI, Logging, and Kubernetes, which are all conceptually under the
+“Airflow Core” area of the project.
+
+Similarly, some providers are broken out such as Apache (``provider/Apache``),
+AWS (``provider/AWS``), Azure (``provider/Azure``), and Google (``provider/Google``).
+These make it easier for developers working on a single provider to
+track issues for that provider.
+
+Most issues need a combination of "kind" and "area" labels to be actionable.
+For example:
+
+* Feature request for an additional API would have ``kind:feature`` and ``area:API``
+* Bug report on the User Interface would have ``kind:bug`` and ``area:UI``
+* Documentation request on the Kubernetes Executor, would have ``kind:documentation`` and ``area:kubernetes``
+
+
+Response to issues
+''''''''''''''''''
+
+Once an issue has been created on the Airflow project, someone from the
+Airflow team or the Airflow community typically responds to this issue.
+This response can have multiple elements.
+
+**Priority**
+
+After significant discussion about the different priority schemes currently
+being used across various projects, we decided to use a priority scheme based
+on the Kubernetes project, since the team felt it was easier for people to
+understand.
+
+Therefore, the priority labels used are:
+
+* ``priority:critical``: Showstopper bug that should be resolved immediately and a patch issued as soon as possible. Typically, this is because it affects most users and would take down production systems.
+* ``priority:high``: A high priority bug that affects many users and should be resolved quickly, but can wait for the next scheduled patch release.
+* ``priority:medium``: A bug that should be fixed before the next release, but would not block a release if found during the release process.
+* ``priority:low``: A bug with a simple workaround or a nuisance that does not stop mainstream functionality.
+
+
+It's important to use priority labels effectively so we can triage incoming issues
+appropriately and make sure that when we release a new version of Airflow,
+we can ship a release confident that there are no “production blocker” issues in it.
Review comment:
We need to clarify if the intention to use priority labels only on Airflow core or also on providers.
in general issue can be critical in a specific provider (broken provider, broken specific package in provider etc..)
If we set `priority:critical` on Google provider. Does this means we expect/suggest/consider a patch release for this provider?
##########
File path: docs/apache-airflow/issue-triage-process.rst
##########
@@ -0,0 +1,195 @@
+ .. 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.
+
+
+
+
+Issue reporting and resolution process
+======================================
+
+This document explains the issue tracking and triage process within Apache
+Airflow including labels, milestones, and priorities as well as the process
+of resolving issues.
+
+Labels
+''''''
+
+Since Apache Airflow uses Github Issues as the issue tracking system, the
+use of labels is extensive. Though issue labels tend to change over time
+based on components within the project, the majority of the ones listed
+below should stand the test of time.
+
+The intention with the use of labels with the Apache Airflow project is
+that they should ideally be non-temporal in nature and primarily used
+to indicate the following elements:
+
+**Kind**
+
+The “kind” labels indicate “what kind of issue it is”. The most
+commonly used “kind” labels are: bug, feature, documentation, or task.
+
+Therefore, when reporting an issue, the label of ``kind:bug`` is to
+indicate a problem with the functionality, whereas the label of
+``kind:feature`` is a desire to extend the functionality.
+
+There has been discussion within the project about whether to separate
+the desire for “new features” from “enhancements to existing features”,
+but in practice most “feature requests” are actually enhancement requests,
+so we decided to combine them both into ``kind:feature``.
+
+We recently introduced ``kind:task`` to categorize issues which are
+identified elements of work to be done, primarily as part of a larger
+change to be done as part of an AIP or something which needs to be cleaned
+up in the project.
+
+Issues of ``kind:documentation`` are for changes which need to be
+made to the documentation within the project.
+
+
+**Area**
+
+The “area” set of labels should indicate the component of the code
+referenced by the issue. At a high level, the biggest areas of the project
+are: Airflow Core and Airflow Providers, which are referenced by ``area:core``
+and ``area:providers``. This is especially important since these are now
+being released and versioned independently.
+
+There are more detailed areas of the project such as Scheduler, Webserver,
+API, UI, Logging, and Kubernetes, which are all conceptually under the
+“Airflow Core” area of the project.
+
+Similarly, some providers are broken out such as Apache (``provider/Apache``),
+AWS (``provider/AWS``), Azure (``provider/Azure``), and Google (``provider/Google``).
+These make it easier for developers working on a single provider to
+track issues for that provider.
Review comment:
Should we mention the motivation why some providers have dedicated labels while other don't?
----------------------------------------------------------------
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
[GitHub] [airflow] vikramkoka commented on a change in pull request #14223: Added Issue reporting and triage process document
Posted by GitBox <gi...@apache.org>.
vikramkoka commented on a change in pull request #14223:
URL: https://github.com/apache/airflow/pull/14223#discussion_r576481923
##########
File path: docs/apache-airflow/issue-triage-process.rst
##########
@@ -0,0 +1,195 @@
+ .. 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.
+
+
+
+
+Issue reporting and resolution process
+======================================
+
+This document explains the issue tracking and triage process within Apache
+Airflow including labels, milestones, and priorities as well as the process
+of resolution of issues.
+
+Labels
+''''''
+
+Since Apache Airflow uses Github Issues as the issue tracking system, the
+use of labels is extensive. Though issue labels tend to change over time
+based on components within the project, the majority of the ones listed
+below should stand the test of time.
+
+The intention with the use of labels with the Apache Airflow project is
+that they should ideally be non-temporal in nature and primarily used
+to indicate the following elements:
+
+**Kind**
+
+The “kind” of labels indicate “what kind of issue it is”. The most
Review comment:
done
##########
File path: docs/apache-airflow/issue-triage-process.rst
##########
@@ -0,0 +1,195 @@
+ .. 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.
+
+
+
+
+Issue reporting and resolution process
+======================================
+
+This document explains the issue tracking and triage process within Apache
+Airflow including labels, milestones, and priorities as well as the process
+of resolution of issues.
+
+Labels
+''''''
+
+Since Apache Airflow uses Github Issues as the issue tracking system, the
+use of labels is extensive. Though issue labels tend to change over time
+based on components within the project, the majority of the ones listed
+below should stand the test of time.
+
+The intention with the use of labels with the Apache Airflow project is
+that they should ideally be non-temporal in nature and primarily used
+to indicate the following elements:
+
+**Kind**
+
+The “kind” of labels indicate “what kind of issue it is”. The most
+commonly used “kind” labels are: bug, feature, documentation, or task.
+
+Therefore, when reporting an issue, the label of ``kind:bug`` is to
+indicate a problem with the functionality, whereas the label of
+``kind:feature`` is a desire to extend the functionality.
+
+There has been discussion within the project about whether to separate
+the desire for “new features” from “enhancements to existing features”,
+but in practice most “feature requests” are actually enhancement requests,
+so we decided to combine them both into ``kind:feature``.
+
+We recently introduced ``kind:task`` to categorize issues which are
+identified elements of work to be done, primarily as part of a larger
+change to be done as part of an AIP or something which needs to be cleaned
+up in the project.
+
+Issues of ``kind:documentation`` are exactly that, changes which need to be
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
[GitHub] [airflow] mik-laj commented on a change in pull request #14223: Added Issue reporting and triage process document
Posted by GitBox <gi...@apache.org>.
mik-laj commented on a change in pull request #14223:
URL: https://github.com/apache/airflow/pull/14223#discussion_r577778526
##########
File path: docs/apache-airflow/index.rst
##########
@@ -104,6 +104,7 @@ unit of work and continuity.
production-deployment
backport-providers
faq
+ Issue reporting and resolution process <issue-triage-process>
Review comment:
The apache-airflow package is versioned according to the apache-airflow release cycle. If you think it is worthwhile for users to have access to this document, we need to consider whether users will have access to a good version of this document. It seems to me that this page is not related to any particular version of apache-airflow and will therefore be out of date very quickly. It may happen that after the first day of release of a new version of apache-airflow, we will want to update the process a bit, e.g. to add new labels, but this will be a bit difficult because we try to keep the documentation immutable. We only update the documentation when a new version is released.
Please note where this page is posted on the website. If you want to go to this article, you will have to go to airflow.apache.org, click "Documentation", click "Apache Airflow", and. finally click "Issue reporting and resolution process". If you want to post it on airflow.apache.org then it's a better idea to add it to the section ["Community"](http://airflow.apache.org/community/), which already describes the rules for reporting bugs.
----------------------------------------------------------------
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
[GitHub] [airflow] potiuk commented on a change in pull request #14223: Added Issue reporting and triage process document
Posted by GitBox <gi...@apache.org>.
potiuk commented on a change in pull request #14223:
URL: https://github.com/apache/airflow/pull/14223#discussion_r577842729
##########
File path: docs/apache-airflow/index.rst
##########
@@ -104,6 +104,7 @@ unit of work and continuity.
production-deployment
backport-providers
faq
+ Issue reporting and resolution process <issue-triage-process>
Review comment:
I agree with @mik-laj. This document is likely to change between releases, so it falls into the same category as CONTRIBUTING.rst or README. I agree that it should be in GitHub rather than in the generated documentation. The best we can do is to have it in GitHub and link to it from the documentation if we want to make users aware of it's existence. Everything it talks about is GitHub issues, so there is no problem with it being in GitHub and not under `airflow.apache.org`.
----------------------------------------------------------------
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
[GitHub] [airflow] vikramkoka commented on a change in pull request #14223: Added Issue reporting and triage process document
Posted by GitBox <gi...@apache.org>.
vikramkoka commented on a change in pull request #14223:
URL: https://github.com/apache/airflow/pull/14223#discussion_r577748569
##########
File path: docs/apache-airflow/index.rst
##########
@@ -104,6 +104,7 @@ unit of work and continuity.
production-deployment
backport-providers
faq
+ Issue reporting and resolution process <issue-triage-process>
Review comment:
I am sorry, I don't understand the question.
----------------------------------------------------------------
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
[GitHub] [airflow] vikramkoka commented on a change in pull request #14223: Added Issue reporting and triage process document
Posted by GitBox <gi...@apache.org>.
vikramkoka commented on a change in pull request #14223:
URL: https://github.com/apache/airflow/pull/14223#discussion_r578699201
##########
File path: docs/apache-airflow/issue-triage-process.rst
##########
@@ -0,0 +1,195 @@
+ .. 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.
+
+
+
+
+Issue reporting and resolution process
+======================================
+
+This document explains the issue tracking and triage process within Apache
+Airflow including labels, milestones, and priorities as well as the process
+of resolving issues.
+
+Labels
+''''''
+
+Since Apache Airflow uses Github Issues as the issue tracking system, the
+use of labels is extensive. Though issue labels tend to change over time
+based on components within the project, the majority of the ones listed
+below should stand the test of time.
+
+The intention with the use of labels with the Apache Airflow project is
+that they should ideally be non-temporal in nature and primarily used
+to indicate the following elements:
+
+**Kind**
+
+The “kind” labels indicate “what kind of issue it is”. The most
+commonly used “kind” labels are: bug, feature, documentation, or task.
+
+Therefore, when reporting an issue, the label of ``kind:bug`` is to
+indicate a problem with the functionality, whereas the label of
+``kind:feature`` is a desire to extend the functionality.
+
+There has been discussion within the project about whether to separate
+the desire for “new features” from “enhancements to existing features”,
+but in practice most “feature requests” are actually enhancement requests,
+so we decided to combine them both into ``kind:feature``.
+
+We recently introduced ``kind:task`` to categorize issues which are
+identified elements of work to be done, primarily as part of a larger
+change to be done as part of an AIP or something which needs to be cleaned
+up in the project.
+
+Issues of ``kind:documentation`` are for changes which need to be
+made to the documentation within the project.
+
+
+**Area**
+
+The “area” set of labels should indicate the component of the code
+referenced by the issue. At a high level, the biggest areas of the project
+are: Airflow Core and Airflow Providers, which are referenced by ``area:core``
+and ``area:providers``. This is especially important since these are now
+being released and versioned independently.
+
+There are more detailed areas of the project such as Scheduler, Webserver,
+API, UI, Logging, and Kubernetes, which are all conceptually under the
+“Airflow Core” area of the project.
+
+Similarly, some providers are broken out such as Apache (``provider/Apache``),
+AWS (``provider/AWS``), Azure (``provider/Azure``), and Google (``provider/Google``).
+These make it easier for developers working on a single provider to
+track issues for that provider.
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
[GitHub] [airflow] potiuk commented on a change in pull request #14223: Added Issue reporting and triage process document
Posted by GitBox <gi...@apache.org>.
potiuk commented on a change in pull request #14223:
URL: https://github.com/apache/airflow/pull/14223#discussion_r577835055
##########
File path: docs/apache-airflow/issue-triage-process.rst
##########
@@ -0,0 +1,195 @@
+ .. 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.
+
+
+
+
+Issue reporting and resolution process
+======================================
+
+This document explains the issue tracking and triage process within Apache
+Airflow including labels, milestones, and priorities as well as the process
+of resolving issues.
+
+Labels
+''''''
+
+Since Apache Airflow uses Github Issues as the issue tracking system, the
+use of labels is extensive. Though issue labels tend to change over time
+based on components within the project, the majority of the ones listed
+below should stand the test of time.
+
+The intention with the use of labels with the Apache Airflow project is
+that they should ideally be non-temporal in nature and primarily used
+to indicate the following elements:
+
+**Kind**
+
+The “kind” labels indicate “what kind of issue it is”. The most
+commonly used “kind” labels are: bug, feature, documentation, or task.
+
+Therefore, when reporting an issue, the label of ``kind:bug`` is to
+indicate a problem with the functionality, whereas the label of
+``kind:feature`` is a desire to extend the functionality.
+
+There has been discussion within the project about whether to separate
+the desire for “new features” from “enhancements to existing features”,
+but in practice most “feature requests” are actually enhancement requests,
+so we decided to combine them both into ``kind:feature``.
+
+We recently introduced ``kind:task`` to categorize issues which are
+identified elements of work to be done, primarily as part of a larger
+change to be done as part of an AIP or something which needs to be cleaned
+up in the project.
+
+Issues of ``kind:documentation`` are for changes which need to be
+made to the documentation within the project.
+
+
+**Area**
+
+The “area” set of labels should indicate the component of the code
+referenced by the issue. At a high level, the biggest areas of the project
+are: Airflow Core and Airflow Providers, which are referenced by ``area:core``
+and ``area:providers``. This is especially important since these are now
+being released and versioned independently.
+
+There are more detailed areas of the project such as Scheduler, Webserver,
+API, UI, Logging, and Kubernetes, which are all conceptually under the
+“Airflow Core” area of the project.
+
+Similarly, some providers are broken out such as Apache (``provider/Apache``),
+AWS (``provider/AWS``), Azure (``provider/Azure``), and Google (``provider/Google``).
+These make it easier for developers working on a single provider to
+track issues for that provider.
+
+Most issues need a combination of "kind" and "area" labels to be actionable.
+For example:
+
+* Feature request for an additional API would have ``kind:feature`` and ``area:API``
+* Bug report on the User Interface would have ``kind:bug`` and ``area:UI``
+* Documentation request on the Kubernetes Executor, would have ``kind:documentation`` and ``area:kubernetes``
+
+
+Response to issues
+''''''''''''''''''
+
+Once an issue has been created on the Airflow project, someone from the
+Airflow team or the Airflow community typically responds to this issue.
+This response can have multiple elements.
+
+**Priority**
+
+After significant discussion about the different priority schemes currently
+being used across various projects, we decided to use a priority scheme based
+on the Kubernetes project, since the team felt it was easier for people to
+understand.
+
+Therefore, the priority labels used are:
+
+* ``priority:critical``: Showstopper bug that should be resolved immediately and a patch issued as soon as possible. Typically, this is because it affects most users and would take down production systems.
+* ``priority:high``: A high priority bug that affects many users and should be resolved quickly, but can wait for the next scheduled patch release.
+* ``priority:medium``: A bug that should be fixed before the next release, but would not block a release if found during the release process.
+* ``priority:low``: A bug with a simple workaround or a nuisance that does not stop mainstream functionality.
+
+
+It's important to use priority labels effectively so we can triage incoming issues
+appropriately and make sure that when we release a new version of Airflow,
+we can ship a release confident that there are no “production blocker” issues in it.
+
+
+**Milestones**
+
+The key temporal element in the issue triage process is the concept of milestones.
+This is critical for release management purposes and will be used represent upcoming
+release targets.
+
+Issues currently being resolved will get assigned to one of the upcoming releases.
+For example a feature request may be targeted for the next feature release milestone
+such as ``2.x``, where a bug may be targeted for the next patch release milestone
+such as ``2.x.y``.
+
+In the interest of being precise, when an issue is tagged with a milestone, it
+represents that it will be considered for that release, not that it is committed to
+a release. Once a PR is created to fix that issue and when that PR is tagged with a
+milestone, it implies that the PR is intended to released in that milestone.
+
+It is worth noting that Airflow Core and Airflow Providers are now released and
Review comment:
Correct. I am planning to propose how formally our provider release process will look like (basically release all provider that changed from master every 3 weeks in regular intervals (RC - 1 week vote - Release - 2 weeks break) - i wanted to discuss it at the dev call today. and in this case we can set a release schedule in calendar rather than a milestone.
----------------------------------------------------------------
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
[GitHub] [airflow] kaxil merged pull request #14223: Added Issue reporting and triage process document
Posted by GitBox <gi...@apache.org>.
kaxil merged pull request #14223:
URL: https://github.com/apache/airflow/pull/14223
----------------------------------------------------------------
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
[GitHub] [airflow] vikramkoka commented on a change in pull request #14223: Added Issue reporting and triage process document
Posted by GitBox <gi...@apache.org>.
vikramkoka commented on a change in pull request #14223:
URL: https://github.com/apache/airflow/pull/14223#discussion_r578683366
##########
File path: docs/apache-airflow/issue-triage-process.rst
##########
@@ -0,0 +1,195 @@
+ .. 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.
+
+
+
+
+Issue reporting and resolution process
+======================================
+
+This document explains the issue tracking and triage process within Apache
+Airflow including labels, milestones, and priorities as well as the process
+of resolving issues.
+
+Labels
+''''''
+
+Since Apache Airflow uses Github Issues as the issue tracking system, the
+use of labels is extensive. Though issue labels tend to change over time
+based on components within the project, the majority of the ones listed
+below should stand the test of time.
+
+The intention with the use of labels with the Apache Airflow project is
+that they should ideally be non-temporal in nature and primarily used
+to indicate the following elements:
+
+**Kind**
+
+The “kind” labels indicate “what kind of issue it is”. The most
+commonly used “kind” labels are: bug, feature, documentation, or task.
+
+Therefore, when reporting an issue, the label of ``kind:bug`` is to
+indicate a problem with the functionality, whereas the label of
+``kind:feature`` is a desire to extend the functionality.
+
+There has been discussion within the project about whether to separate
+the desire for “new features” from “enhancements to existing features”,
+but in practice most “feature requests” are actually enhancement requests,
+so we decided to combine them both into ``kind:feature``.
+
+We recently introduced ``kind:task`` to categorize issues which are
+identified elements of work to be done, primarily as part of a larger
+change to be done as part of an AIP or something which needs to be cleaned
+up in the project.
+
+Issues of ``kind:documentation`` are for changes which need to be
+made to the documentation within the project.
+
+
+**Area**
+
+The “area” set of labels should indicate the component of the code
+referenced by the issue. At a high level, the biggest areas of the project
+are: Airflow Core and Airflow Providers, which are referenced by ``area:core``
+and ``area:providers``. This is especially important since these are now
+being released and versioned independently.
+
+There are more detailed areas of the project such as Scheduler, Webserver,
+API, UI, Logging, and Kubernetes, which are all conceptually under the
+“Airflow Core” area of the project.
+
+Similarly, some providers are broken out such as Apache (``provider/Apache``),
+AWS (``provider/AWS``), Azure (``provider/Azure``), and Google (``provider/Google``).
+These make it easier for developers working on a single provider to
+track issues for that provider.
+
+Most issues need a combination of "kind" and "area" labels to be actionable.
+For example:
+
+* Feature request for an additional API would have ``kind:feature`` and ``area:API``
+* Bug report on the User Interface would have ``kind:bug`` and ``area:UI``
+* Documentation request on the Kubernetes Executor, would have ``kind:documentation`` and ``area:kubernetes``
+
+
+Response to issues
+''''''''''''''''''
+
+Once an issue has been created on the Airflow project, someone from the
+Airflow team or the Airflow community typically responds to this issue.
+This response can have multiple elements.
+
+**Priority**
+
+After significant discussion about the different priority schemes currently
+being used across various projects, we decided to use a priority scheme based
+on the Kubernetes project, since the team felt it was easier for people to
+understand.
+
+Therefore, the priority labels used are:
+
+* ``priority:critical``: Showstopper bug that should be resolved immediately and a patch issued as soon as possible. Typically, this is because it affects most users and would take down production systems.
+* ``priority:high``: A high priority bug that affects many users and should be resolved quickly, but can wait for the next scheduled patch release.
+* ``priority:medium``: A bug that should be fixed before the next release, but would not block a release if found during the release process.
+* ``priority:low``: A bug with a simple workaround or a nuisance that does not stop mainstream functionality.
+
+
+It's important to use priority labels effectively so we can triage incoming issues
+appropriately and make sure that when we release a new version of Airflow,
+we can ship a release confident that there are no “production blocker” issues in it.
Review comment:
Thank you, great point. done.
##########
File path: docs/apache-airflow/issue-triage-process.rst
##########
@@ -0,0 +1,195 @@
+ .. 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.
+
+
+
+
+Issue reporting and resolution process
+======================================
+
+This document explains the issue tracking and triage process within Apache
+Airflow including labels, milestones, and priorities as well as the process
+of resolving issues.
Review comment:
Good point, 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
[GitHub] [airflow] github-actions[bot] commented on pull request #14223: Added Issue reporting and triage process document
Posted by GitBox <gi...@apache.org>.
github-actions[bot] commented on pull request #14223:
URL: https://github.com/apache/airflow/pull/14223#issuecomment-781606551
[The Workflow run](https://github.com/apache/airflow/actions/runs/579278314) is cancelling this PR. Building images for the PR has failed. Follow the the workflow link to check the reason.
----------------------------------------------------------------
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
[GitHub] [airflow] jhtimmins commented on a change in pull request #14223: Added Issue reporting and triage process document
Posted by GitBox <gi...@apache.org>.
jhtimmins commented on a change in pull request #14223:
URL: https://github.com/apache/airflow/pull/14223#discussion_r575755810
##########
File path: docs/apache-airflow/issue-triage-process.rst
##########
@@ -0,0 +1,195 @@
+ .. 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.
+
+
+
+
+Issue reporting and resolution process
+======================================
+
+This document explains the issue tracking and triage process within Apache
+Airflow including labels, milestones, and priorities as well as the process
+of resolution of issues.
Review comment:
```suggestion
of resolving issues.
```
##########
File path: docs/apache-airflow/issue-triage-process.rst
##########
@@ -0,0 +1,195 @@
+ .. 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.
+
+
+
+
+Issue reporting and resolution process
+======================================
+
+This document explains the issue tracking and triage process within Apache
+Airflow including labels, milestones, and priorities as well as the process
+of resolution of issues.
+
+Labels
+''''''
+
+Since Apache Airflow uses Github Issues as the issue tracking system, the
+use of labels is extensive. Though issue labels tend to change over time
+based on components within the project, the majority of the ones listed
+below should stand the test of time.
+
+The intention with the use of labels with the Apache Airflow project is
+that they should ideally be non-temporal in nature and primarily used
+to indicate the following elements:
+
+**Kind**
+
+The “kind” of labels indicate “what kind of issue it is”. The most
Review comment:
```suggestion
The “kind” labels indicate “what kind of issue it is”. The most
```
##########
File path: docs/apache-airflow/issue-triage-process.rst
##########
@@ -0,0 +1,195 @@
+ .. 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.
+
+
+
+
+Issue reporting and resolution process
+======================================
+
+This document explains the issue tracking and triage process within Apache
+Airflow including labels, milestones, and priorities as well as the process
+of resolution of issues.
+
+Labels
+''''''
+
+Since Apache Airflow uses Github Issues as the issue tracking system, the
+use of labels is extensive. Though issue labels tend to change over time
+based on components within the project, the majority of the ones listed
+below should stand the test of time.
+
+The intention with the use of labels with the Apache Airflow project is
+that they should ideally be non-temporal in nature and primarily used
+to indicate the following elements:
+
+**Kind**
+
+The “kind” of labels indicate “what kind of issue it is”. The most
+commonly used “kind” labels are: bug, feature, documentation, or task.
+
+Therefore, when reporting an issue, the label of ``kind:bug`` is to
+indicate a problem with the functionality, whereas the label of
+``kind:feature`` is a desire to extend the functionality.
+
+There has been discussion within the project about whether to separate
+the desire for “new features” from “enhancements to existing features”,
+but in practice most “feature requests” are actually enhancement requests,
+so we decided to combine them both into ``kind:feature``.
+
+We recently introduced ``kind:task`` to categorize issues which are
+identified elements of work to be done, primarily as part of a larger
+change to be done as part of an AIP or something which needs to be cleaned
+up in the project.
+
+Issues of ``kind:documentation`` are exactly that, changes which need to be
+made to the documentation within the project.
+
+
+**Area**
+
+The “area” set of labels should indicate the component of the code
+referenced by the issue. At a high level, the biggest areas of the project
+are: Airflow Core and Airflow Providers, which are referenced by ``area:core``
+and ``area:providers``. This is especially important since these are now
+being released and versioned independently.
+
+There are more detailed areas of the project such as Scheduler, Webserver,
+API, UI, Logging, and Kubernetes which are all conceptually under the
+“Airflow Core” area of the project.
+
+Similarly, some providers are broken out such as Apache (``provider/Apache``),
+AWS (``provider/AWS``), Azure (``provider/Azure``), and Google (``provider/Google``).
+These make it easier for developers working on a single provider to
+track issues for that provider.
+
+Most issues need a combination of "kind" and "area" labels to be actionable.
+For example:
+
+* Feature request for an additional API would have ``kind:feature`` and ``area:API``
+* Bug report on the User Interface would have ``kind:bug`` and ``area:UI``
+* Documentation request on the Kubernetes Executor, would have ``kind:documentation`` and ``area:kubernetes``
+
+
+Response to issues
+''''''''''''''''''
+
+Once an issue has been created on the Airflow project, someone from the
+Airflow team or the Airflow community typically responds to this issue.
+This response can have multiple elements.
+
+**Priority**
+
+After significant discussion about the different priority schemes currently
+being used across various projects, we decided to use a priority scheme based
+on the Kubernetes project, since the team felt it was easier for people to
+understand.
+
+Therefore, the priority labels used are:
+
+* ``Priority:critical``: Showstopper bug that should be resolved immediately and a patch issued as soon as possible. Typically, this is because it affects most users and would take down production systems.
+* ``Priority:high``: A high priority bug that affects many users and should be resolved quickly, but can wait for the next scheduled patch release.
+* ``Priority:medium``: A bug that should be fixed before the next release, but would not block a release if found during the release process.
+* ``Priority:low``: A bug with a simple workaround or a nuisance that does not stop mainstream functionality.
+
+
+The importance of using priority effectively is to both triage incoming issues
+appropriately as well to make sure that when we release a new version of Airflow,
+we can ship a release confident that there are no “production blocker” issues in it.
Review comment:
```suggestion
It's important to use priority labels effectively so we can triage incoming issues
appropriately and make sure that when we release a new version of Airflow,
we can ship a release confident that there are no “production blocker” issues in it.
```
##########
File path: docs/apache-airflow/issue-triage-process.rst
##########
@@ -0,0 +1,195 @@
+ .. 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.
+
+
+
+
+Issue reporting and resolution process
+======================================
+
+This document explains the issue tracking and triage process within Apache
+Airflow including labels, milestones, and priorities as well as the process
+of resolution of issues.
+
+Labels
+''''''
+
+Since Apache Airflow uses Github Issues as the issue tracking system, the
+use of labels is extensive. Though issue labels tend to change over time
+based on components within the project, the majority of the ones listed
+below should stand the test of time.
+
+The intention with the use of labels with the Apache Airflow project is
+that they should ideally be non-temporal in nature and primarily used
+to indicate the following elements:
+
+**Kind**
+
+The “kind” of labels indicate “what kind of issue it is”. The most
+commonly used “kind” labels are: bug, feature, documentation, or task.
+
+Therefore, when reporting an issue, the label of ``kind:bug`` is to
+indicate a problem with the functionality, whereas the label of
+``kind:feature`` is a desire to extend the functionality.
+
+There has been discussion within the project about whether to separate
+the desire for “new features” from “enhancements to existing features”,
+but in practice most “feature requests” are actually enhancement requests,
+so we decided to combine them both into ``kind:feature``.
+
+We recently introduced ``kind:task`` to categorize issues which are
+identified elements of work to be done, primarily as part of a larger
+change to be done as part of an AIP or something which needs to be cleaned
+up in the project.
+
+Issues of ``kind:documentation`` are exactly that, changes which need to be
+made to the documentation within the project.
+
+
+**Area**
+
+The “area” set of labels should indicate the component of the code
+referenced by the issue. At a high level, the biggest areas of the project
+are: Airflow Core and Airflow Providers, which are referenced by ``area:core``
+and ``area:providers``. This is especially important since these are now
+being released and versioned independently.
+
+There are more detailed areas of the project such as Scheduler, Webserver,
+API, UI, Logging, and Kubernetes which are all conceptually under the
+“Airflow Core” area of the project.
+
+Similarly, some providers are broken out such as Apache (``provider/Apache``),
+AWS (``provider/AWS``), Azure (``provider/Azure``), and Google (``provider/Google``).
+These make it easier for developers working on a single provider to
+track issues for that provider.
+
+Most issues need a combination of "kind" and "area" labels to be actionable.
+For example:
+
+* Feature request for an additional API would have ``kind:feature`` and ``area:API``
+* Bug report on the User Interface would have ``kind:bug`` and ``area:UI``
+* Documentation request on the Kubernetes Executor, would have ``kind:documentation`` and ``area:kubernetes``
+
+
+Response to issues
+''''''''''''''''''
+
+Once an issue has been created on the Airflow project, someone from the
+Airflow team or the Airflow community typically responds to this issue.
+This response can have multiple elements.
+
+**Priority**
+
+After significant discussion about the different priority schemes currently
+being used across various projects, we decided to use a priority scheme based
+on the Kubernetes project, since the team felt it was easier for people to
+understand.
+
+Therefore, the priority labels used are:
+
+* ``Priority:critical``: Showstopper bug that should be resolved immediately and a patch issued as soon as possible. Typically, this is because it affects most users and would take down production systems.
Review comment:
Does it make sense to capitalize the `Priority` prefix if we don't capitalize `area`?
##########
File path: docs/apache-airflow/issue-triage-process.rst
##########
@@ -0,0 +1,195 @@
+ .. 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.
+
+
+
+
+Issue reporting and resolution process
+======================================
+
+This document explains the issue tracking and triage process within Apache
+Airflow including labels, milestones, and priorities as well as the process
+of resolution of issues.
+
+Labels
+''''''
+
+Since Apache Airflow uses Github Issues as the issue tracking system, the
+use of labels is extensive. Though issue labels tend to change over time
+based on components within the project, the majority of the ones listed
+below should stand the test of time.
+
+The intention with the use of labels with the Apache Airflow project is
+that they should ideally be non-temporal in nature and primarily used
+to indicate the following elements:
+
+**Kind**
+
+The “kind” of labels indicate “what kind of issue it is”. The most
+commonly used “kind” labels are: bug, feature, documentation, or task.
+
+Therefore, when reporting an issue, the label of ``kind:bug`` is to
+indicate a problem with the functionality, whereas the label of
+``kind:feature`` is a desire to extend the functionality.
+
+There has been discussion within the project about whether to separate
+the desire for “new features” from “enhancements to existing features”,
+but in practice most “feature requests” are actually enhancement requests,
+so we decided to combine them both into ``kind:feature``.
+
+We recently introduced ``kind:task`` to categorize issues which are
+identified elements of work to be done, primarily as part of a larger
+change to be done as part of an AIP or something which needs to be cleaned
+up in the project.
+
+Issues of ``kind:documentation`` are exactly that, changes which need to be
Review comment:
```suggestion
Issues of ``kind:documentation`` are for changes which need to be
```
##########
File path: docs/apache-airflow/issue-triage-process.rst
##########
@@ -0,0 +1,195 @@
+ .. 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.
+
+
+
+
+Issue reporting and resolution process
+======================================
+
+This document explains the issue tracking and triage process within Apache
+Airflow including labels, milestones, and priorities as well as the process
+of resolution of issues.
+
+Labels
+''''''
+
+Since Apache Airflow uses Github Issues as the issue tracking system, the
+use of labels is extensive. Though issue labels tend to change over time
+based on components within the project, the majority of the ones listed
+below should stand the test of time.
+
+The intention with the use of labels with the Apache Airflow project is
+that they should ideally be non-temporal in nature and primarily used
+to indicate the following elements:
+
+**Kind**
+
+The “kind” of labels indicate “what kind of issue it is”. The most
+commonly used “kind” labels are: bug, feature, documentation, or task.
+
+Therefore, when reporting an issue, the label of ``kind:bug`` is to
+indicate a problem with the functionality, whereas the label of
+``kind:feature`` is a desire to extend the functionality.
+
+There has been discussion within the project about whether to separate
+the desire for “new features” from “enhancements to existing features”,
+but in practice most “feature requests” are actually enhancement requests,
+so we decided to combine them both into ``kind:feature``.
+
+We recently introduced ``kind:task`` to categorize issues which are
+identified elements of work to be done, primarily as part of a larger
+change to be done as part of an AIP or something which needs to be cleaned
+up in the project.
+
+Issues of ``kind:documentation`` are exactly that, changes which need to be
+made to the documentation within the project.
+
+
+**Area**
+
+The “area” set of labels should indicate the component of the code
+referenced by the issue. At a high level, the biggest areas of the project
+are: Airflow Core and Airflow Providers, which are referenced by ``area:core``
+and ``area:providers``. This is especially important since these are now
+being released and versioned independently.
+
+There are more detailed areas of the project such as Scheduler, Webserver,
+API, UI, Logging, and Kubernetes which are all conceptually under the
Review comment:
```suggestion
API, UI, Logging, and Kubernetes, which are all conceptually under the
```
----------------------------------------------------------------
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
[GitHub] [airflow] mik-laj commented on a change in pull request #14223: Added Issue reporting and triage process document
Posted by GitBox <gi...@apache.org>.
mik-laj commented on a change in pull request #14223:
URL: https://github.com/apache/airflow/pull/14223#discussion_r575771073
##########
File path: docs/apache-airflow/index.rst
##########
@@ -104,6 +104,7 @@ unit of work and continuity.
production-deployment
backport-providers
faq
+ Issue reporting and resolution process <issue-triage-process>
Review comment:
Is this documentation intended for the end user or for a contributor? I think it would be better if this link got added to CONTRIBUTING.rst.
----------------------------------------------------------------
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
[GitHub] [airflow] vikramkoka commented on a change in pull request #14223: Added Issue reporting and triage process document
Posted by GitBox <gi...@apache.org>.
vikramkoka commented on a change in pull request #14223:
URL: https://github.com/apache/airflow/pull/14223#discussion_r577739619
##########
File path: docs/apache-airflow/issue-triage-process.rst
##########
@@ -0,0 +1,195 @@
+ .. 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.
+
+
+
+
+Issue reporting and resolution process
+======================================
+
+This document explains the issue tracking and triage process within Apache
+Airflow including labels, milestones, and priorities as well as the process
+of resolving issues.
+
+Labels
+''''''
+
+Since Apache Airflow uses Github Issues as the issue tracking system, the
+use of labels is extensive. Though issue labels tend to change over time
+based on components within the project, the majority of the ones listed
+below should stand the test of time.
+
+The intention with the use of labels with the Apache Airflow project is
+that they should ideally be non-temporal in nature and primarily used
+to indicate the following elements:
+
+**Kind**
+
+The “kind” labels indicate “what kind of issue it is”. The most
+commonly used “kind” labels are: bug, feature, documentation, or task.
+
+Therefore, when reporting an issue, the label of ``kind:bug`` is to
+indicate a problem with the functionality, whereas the label of
+``kind:feature`` is a desire to extend the functionality.
+
+There has been discussion within the project about whether to separate
+the desire for “new features” from “enhancements to existing features”,
+but in practice most “feature requests” are actually enhancement requests,
+so we decided to combine them both into ``kind:feature``.
+
+We recently introduced ``kind:task`` to categorize issues which are
+identified elements of work to be done, primarily as part of a larger
+change to be done as part of an AIP or something which needs to be cleaned
+up in the project.
+
+Issues of ``kind:documentation`` are for changes which need to be
+made to the documentation within the project.
+
+
+**Area**
+
+The “area” set of labels should indicate the component of the code
+referenced by the issue. At a high level, the biggest areas of the project
+are: Airflow Core and Airflow Providers, which are referenced by ``area:core``
+and ``area:providers``. This is especially important since these are now
+being released and versioned independently.
+
+There are more detailed areas of the project such as Scheduler, Webserver,
+API, UI, Logging, and Kubernetes, which are all conceptually under the
+“Airflow Core” area of the project.
+
+Similarly, some providers are broken out such as Apache (``provider/Apache``),
+AWS (``provider/AWS``), Azure (``provider/Azure``), and Google (``provider/Google``).
+These make it easier for developers working on a single provider to
+track issues for that provider.
+
+Most issues need a combination of "kind" and "area" labels to be actionable.
+For example:
+
+* Feature request for an additional API would have ``kind:feature`` and ``area:API``
+* Bug report on the User Interface would have ``kind:bug`` and ``area:UI``
+* Documentation request on the Kubernetes Executor, would have ``kind:documentation`` and ``area:kubernetes``
+
+
+Response to issues
+''''''''''''''''''
+
+Once an issue has been created on the Airflow project, someone from the
+Airflow team or the Airflow community typically responds to this issue.
+This response can have multiple elements.
+
+**Priority**
+
+After significant discussion about the different priority schemes currently
+being used across various projects, we decided to use a priority scheme based
+on the Kubernetes project, since the team felt it was easier for people to
+understand.
+
+Therefore, the priority labels used are:
+
+* ``priority:critical``: Showstopper bug that should be resolved immediately and a patch issued as soon as possible. Typically, this is because it affects most users and would take down production systems.
+* ``priority:high``: A high priority bug that affects many users and should be resolved quickly, but can wait for the next scheduled patch release.
+* ``priority:medium``: A bug that should be fixed before the next release, but would not block a release if found during the release process.
+* ``priority:low``: A bug with a simple workaround or a nuisance that does not stop mainstream functionality.
+
+
+It's important to use priority labels effectively so we can triage incoming issues
+appropriately and make sure that when we release a new version of Airflow,
+we can ship a release confident that there are no “production blocker” issues in it.
+
+
+**Milestones**
+
+The key temporal element in the issue triage process is the concept of milestones.
+This is critical for release management purposes and will be used represent upcoming
+release targets.
+
+Issues currently being resolved will get assigned to one of the upcoming releases.
+For example a feature request may be targeted for the next feature release milestone
+such as ``2.x``, where a bug may be targeted for the next patch release milestone
+such as ``2.x.y``.
+
+In the interest of being precise, when an issue is tagged with a milestone, it
+represents that it will be considered for that release, not that it is committed to
+a release. Once a PR is created to fix that issue and when that PR is tagged with a
+milestone, it implies that the PR is intended to released in that milestone.
+
+It is worth noting that Airflow Core and Airflow Providers are now released and
Review comment:
Hmm, that's a good point.
I was basing this on the behavior to date including the milestone "apache-airflow-providers-google v2" which is currently there in github issues.
I think you are making the point, that going forward this should be an exception rather than the rule.
Did I understand you correctly?
----------------------------------------------------------------
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
[GitHub] [airflow] potiuk commented on a change in pull request #14223: Added Issue reporting and triage process document
Posted by GitBox <gi...@apache.org>.
potiuk commented on a change in pull request #14223:
URL: https://github.com/apache/airflow/pull/14223#discussion_r577839157
##########
File path: docs/apache-airflow/issue-triage-process.rst
##########
@@ -0,0 +1,195 @@
+ .. 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.
+
+
+
+
+Issue reporting and resolution process
+======================================
+
+This document explains the issue tracking and triage process within Apache
+Airflow including labels, milestones, and priorities as well as the process
+of resolving issues.
Review comment:
Agree. Good point. People do not realise that -it's a rare thing not having to open issue. I think we are pioneers with that. i actually find it pretty cool that we base all that we do on PR numbers rather than issue numbers. This is sooo much less overhead, but people do not realise that this is the case.
Actually we could even modify our template for new issues to include that information alongside "Please save some trees and do not create issue if you can just open PR fixing the problem" ;).
----------------------------------------------------------------
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
[GitHub] [airflow] potiuk commented on a change in pull request #14223: Added Issue reporting and triage process document
Posted by GitBox <gi...@apache.org>.
potiuk commented on a change in pull request #14223:
URL: https://github.com/apache/airflow/pull/14223#discussion_r576541789
##########
File path: docs/apache-airflow/issue-triage-process.rst
##########
@@ -0,0 +1,195 @@
+ .. 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.
+
+
+
+
+Issue reporting and resolution process
+======================================
+
+This document explains the issue tracking and triage process within Apache
+Airflow including labels, milestones, and priorities as well as the process
+of resolving issues.
+
+Labels
+''''''
+
+Since Apache Airflow uses Github Issues as the issue tracking system, the
+use of labels is extensive. Though issue labels tend to change over time
+based on components within the project, the majority of the ones listed
+below should stand the test of time.
+
+The intention with the use of labels with the Apache Airflow project is
+that they should ideally be non-temporal in nature and primarily used
+to indicate the following elements:
+
+**Kind**
+
+The “kind” labels indicate “what kind of issue it is”. The most
+commonly used “kind” labels are: bug, feature, documentation, or task.
+
+Therefore, when reporting an issue, the label of ``kind:bug`` is to
+indicate a problem with the functionality, whereas the label of
+``kind:feature`` is a desire to extend the functionality.
+
+There has been discussion within the project about whether to separate
+the desire for “new features” from “enhancements to existing features”,
+but in practice most “feature requests” are actually enhancement requests,
+so we decided to combine them both into ``kind:feature``.
+
+We recently introduced ``kind:task`` to categorize issues which are
+identified elements of work to be done, primarily as part of a larger
+change to be done as part of an AIP or something which needs to be cleaned
+up in the project.
+
+Issues of ``kind:documentation`` are for changes which need to be
+made to the documentation within the project.
+
+
+**Area**
+
+The “area” set of labels should indicate the component of the code
+referenced by the issue. At a high level, the biggest areas of the project
+are: Airflow Core and Airflow Providers, which are referenced by ``area:core``
+and ``area:providers``. This is especially important since these are now
+being released and versioned independently.
+
+There are more detailed areas of the project such as Scheduler, Webserver,
+API, UI, Logging, and Kubernetes, which are all conceptually under the
+“Airflow Core” area of the project.
+
+Similarly, some providers are broken out such as Apache (``provider/Apache``),
+AWS (``provider/AWS``), Azure (``provider/Azure``), and Google (``provider/Google``).
+These make it easier for developers working on a single provider to
+track issues for that provider.
+
+Most issues need a combination of "kind" and "area" labels to be actionable.
+For example:
+
+* Feature request for an additional API would have ``kind:feature`` and ``area:API``
+* Bug report on the User Interface would have ``kind:bug`` and ``area:UI``
+* Documentation request on the Kubernetes Executor, would have ``kind:documentation`` and ``area:kubernetes``
+
+
+Response to issues
+''''''''''''''''''
+
+Once an issue has been created on the Airflow project, someone from the
+Airflow team or the Airflow community typically responds to this issue.
+This response can have multiple elements.
+
+**Priority**
+
+After significant discussion about the different priority schemes currently
+being used across various projects, we decided to use a priority scheme based
+on the Kubernetes project, since the team felt it was easier for people to
+understand.
+
+Therefore, the priority labels used are:
+
+* ``priority:critical``: Showstopper bug that should be resolved immediately and a patch issued as soon as possible. Typically, this is because it affects most users and would take down production systems.
+* ``priority:high``: A high priority bug that affects many users and should be resolved quickly, but can wait for the next scheduled patch release.
+* ``priority:medium``: A bug that should be fixed before the next release, but would not block a release if found during the release process.
+* ``priority:low``: A bug with a simple workaround or a nuisance that does not stop mainstream functionality.
+
+
+It's important to use priority labels effectively so we can triage incoming issues
+appropriately and make sure that when we release a new version of Airflow,
+we can ship a release confident that there are no “production blocker” issues in it.
+
+
+**Milestones**
+
+The key temporal element in the issue triage process is the concept of milestones.
+This is critical for release management purposes and will be used represent upcoming
+release targets.
+
+Issues currently being resolved will get assigned to one of the upcoming releases.
+For example a feature request may be targeted for the next feature release milestone
+such as ``2.x``, where a bug may be targeted for the next patch release milestone
+such as ``2.x.y``.
+
+In the interest of being precise, when an issue is tagged with a milestone, it
+represents that it will be considered for that release, not that it is committed to
+a release. Once a PR is created to fix that issue and when that PR is tagged with a
+milestone, it implies that the PR is intended to released in that milestone.
+
+It is worth noting that Airflow Core and Airflow Providers are now released and
Review comment:
I am not sure if we want to actually have milestones for Providers. We could have a separate milestone for every batch of providers for sure, but I think this is not necessary, as we will always release whatever we have in master as the next wave of providers. What is more important is a list of upcoming changes in providers - so an automated way to show what will be included in the next wave of providers (so everything that is merged already) - and we will have a separate issue which will get updated automatically with:
* list of providers that we will release (i.e. all providers that have some changes)
* for each provider, detailed list of changes that we will release
This list will be automatically updated and once we release a next wave of providers, it will clean-up automatically.
I believe this is a bit different than core Airflow. For Airflow we deliberately choose what we are going to release by cherry-picking (at least for patchlevels), where for Providers we always release everything we have in master.
----------------------------------------------------------------
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
[GitHub] [airflow] potiuk commented on a change in pull request #14223: Added Issue reporting and triage process document
Posted by GitBox <gi...@apache.org>.
potiuk commented on a change in pull request #14223:
URL: https://github.com/apache/airflow/pull/14223#discussion_r577842729
##########
File path: docs/apache-airflow/index.rst
##########
@@ -104,6 +104,7 @@ unit of work and continuity.
production-deployment
backport-providers
faq
+ Issue reporting and resolution process <issue-triage-process>
Review comment:
I agree with @mik-laj. This document is likely to change between releases, so it falls into the same category as CONTRIBUTING.rst or README. I agree that it should be in GitHub rather than in the generated documentation. The best we can do is to have it in GitHub and link to it from the documentation if we want to make users aware of its existence. Everything it talks about is GitHub issues, so there is no problem with it being in GitHub and not under `airflow.apache.org`.
----------------------------------------------------------------
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
[GitHub] [airflow] vikramkoka commented on a change in pull request #14223: Added Issue reporting and triage process document
Posted by GitBox <gi...@apache.org>.
vikramkoka commented on a change in pull request #14223:
URL: https://github.com/apache/airflow/pull/14223#discussion_r578683039
##########
File path: docs/apache-airflow/issue-triage-process.rst
##########
@@ -0,0 +1,195 @@
+ .. 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.
+
+
+
+
+Issue reporting and resolution process
+======================================
+
+This document explains the issue tracking and triage process within Apache
+Airflow including labels, milestones, and priorities as well as the process
+of resolving issues.
+
+Labels
+''''''
+
+Since Apache Airflow uses Github Issues as the issue tracking system, the
+use of labels is extensive. Though issue labels tend to change over time
+based on components within the project, the majority of the ones listed
+below should stand the test of time.
+
+The intention with the use of labels with the Apache Airflow project is
+that they should ideally be non-temporal in nature and primarily used
+to indicate the following elements:
+
+**Kind**
+
+The “kind” labels indicate “what kind of issue it is”. The most
+commonly used “kind” labels are: bug, feature, documentation, or task.
+
+Therefore, when reporting an issue, the label of ``kind:bug`` is to
+indicate a problem with the functionality, whereas the label of
+``kind:feature`` is a desire to extend the functionality.
+
+There has been discussion within the project about whether to separate
+the desire for “new features” from “enhancements to existing features”,
+but in practice most “feature requests” are actually enhancement requests,
+so we decided to combine them both into ``kind:feature``.
+
+We recently introduced ``kind:task`` to categorize issues which are
+identified elements of work to be done, primarily as part of a larger
+change to be done as part of an AIP or something which needs to be cleaned
+up in the project.
+
+Issues of ``kind:documentation`` are for changes which need to be
+made to the documentation within the project.
+
+
+**Area**
+
+The “area” set of labels should indicate the component of the code
+referenced by the issue. At a high level, the biggest areas of the project
+are: Airflow Core and Airflow Providers, which are referenced by ``area:core``
+and ``area:providers``. This is especially important since these are now
+being released and versioned independently.
+
+There are more detailed areas of the project such as Scheduler, Webserver,
+API, UI, Logging, and Kubernetes, which are all conceptually under the
+“Airflow Core” area of the project.
+
+Similarly, some providers are broken out such as Apache (``provider/Apache``),
+AWS (``provider/AWS``), Azure (``provider/Azure``), and Google (``provider/Google``).
+These make it easier for developers working on a single provider to
+track issues for that provider.
+
+Most issues need a combination of "kind" and "area" labels to be actionable.
+For example:
+
+* Feature request for an additional API would have ``kind:feature`` and ``area:API``
+* Bug report on the User Interface would have ``kind:bug`` and ``area:UI``
+* Documentation request on the Kubernetes Executor, would have ``kind:documentation`` and ``area:kubernetes``
+
+
+Response to issues
+''''''''''''''''''
+
+Once an issue has been created on the Airflow project, someone from the
+Airflow team or the Airflow community typically responds to this issue.
+This response can have multiple elements.
+
+**Priority**
+
+After significant discussion about the different priority schemes currently
+being used across various projects, we decided to use a priority scheme based
+on the Kubernetes project, since the team felt it was easier for people to
+understand.
+
+Therefore, the priority labels used are:
+
+* ``priority:critical``: Showstopper bug that should be resolved immediately and a patch issued as soon as possible. Typically, this is because it affects most users and would take down production systems.
+* ``priority:high``: A high priority bug that affects many users and should be resolved quickly, but can wait for the next scheduled patch release.
+* ``priority:medium``: A bug that should be fixed before the next release, but would not block a release if found during the release process.
+* ``priority:low``: A bug with a simple workaround or a nuisance that does not stop mainstream functionality.
+
+
+It's important to use priority labels effectively so we can triage incoming issues
+appropriately and make sure that when we release a new version of Airflow,
+we can ship a release confident that there are no “production blocker” issues in it.
+
+
+**Milestones**
+
+The key temporal element in the issue triage process is the concept of milestones.
+This is critical for release management purposes and will be used represent upcoming
+release targets.
+
+Issues currently being resolved will get assigned to one of the upcoming releases.
+For example a feature request may be targeted for the next feature release milestone
+such as ``2.x``, where a bug may be targeted for the next patch release milestone
+such as ``2.x.y``.
+
+In the interest of being precise, when an issue is tagged with a milestone, it
+represents that it will be considered for that release, not that it is committed to
+a release. Once a PR is created to fix that issue and when that PR is tagged with a
+milestone, it implies that the PR is intended to released in that milestone.
+
+It is worth noting that Airflow Core and Airflow Providers are now released and
+versioned separately, so they may have a different set of milestones.
+
+
+**Transient Labels**
+
+Sometimes, there is more information needed to either understand the issue or
+to be able to reproduce the issue. Typically, this may require a response to the
+issue creator asking for more information, with the issue then being tagged with
+the label ``pending-response``.
+Also, during this stage, additional labels may be added to the issue to help
+classification and triage, such as ``reported_version`` and ``area``.
+
+Occasionally an issue may require a larger discussion among the Airflow PMC or
+the developer mailing list. This issue may then be tagged with the
+``needs:discussion`` label.
+
+Some issues may need a detailed review by one of the core committers of the project
+and this could be tagged with a ``needs:triage`` label.
+
+
+**Good First Issue**
+
+Issues which are relatively straight forward to solve, will be tagged with
+the ``GoodFirstIssue`` label.
+
+The intention here is to galvanize contributions from new and inexperienced
+contributors who are looking to contribute to the project. This has been successful
+in other open source projects and early signs are that this has been helpful in the
+Airflow project as well.
+
+Ideally, these issues only require one or two files to be changed. The intention
+here is that incremental changes to existing files are a lot easier for a new
+contributor as compared to adding something completely new.
+
+Another possibility here is to add “how to fix” in the comments of such issues, so
+that new contributors have a running start when then pick up these issues.
+
+
+**Timeliness**
+
+For the sake of quick responses, the general “soft" rule within the Airflow project
+is that if there is no assignee, anyone can take an issue to solve.
+
+However, this depends on timely resolution of the issue by the assignee. The
+expectation is as follows:
+
+* If there is no activity on the issue for 2 weeks, the assignee will be reminded about the issue and asked if they are still working on it.
+* If there is no activity even after 1 more week, the issue will be unassigned, so that someone else can pick it up and work on it.
+
+
+There is a similar process when additional information is requested from the
+issue creator. After the pending-response label has been assigned, if there is no
+further information for a period of 1 month, the issue will be automatically closed.
+
+
+
+**Invalidity**
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
[GitHub] [airflow] mik-laj commented on a change in pull request #14223: Added Issue reporting and triage process document
Posted by GitBox <gi...@apache.org>.
mik-laj commented on a change in pull request #14223:
URL: https://github.com/apache/airflow/pull/14223#discussion_r576538812
##########
File path: docs/apache-airflow/index.rst
##########
@@ -104,6 +104,7 @@ unit of work and continuity.
production-deployment
backport-providers
faq
+ Issue reporting and resolution process <issue-triage-process>
Review comment:
how often do these rules change? as often as a new release comes out, or more often? Is it related to specific Airflow version?
----------------------------------------------------------------
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
[GitHub] [airflow] vikramkoka commented on a change in pull request #14223: Added Issue reporting and triage process document
Posted by GitBox <gi...@apache.org>.
vikramkoka commented on a change in pull request #14223:
URL: https://github.com/apache/airflow/pull/14223#discussion_r576481840
##########
File path: docs/apache-airflow/issue-triage-process.rst
##########
@@ -0,0 +1,195 @@
+ .. 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.
+
+
+
+
+Issue reporting and resolution process
+======================================
+
+This document explains the issue tracking and triage process within Apache
+Airflow including labels, milestones, and priorities as well as the process
+of resolution of issues.
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
[GitHub] [airflow] vikramkoka commented on a change in pull request #14223: Added Issue reporting and triage process document
Posted by GitBox <gi...@apache.org>.
vikramkoka commented on a change in pull request #14223:
URL: https://github.com/apache/airflow/pull/14223#discussion_r576482482
##########
File path: docs/apache-airflow/index.rst
##########
@@ -104,6 +104,7 @@ unit of work and continuity.
production-deployment
backport-providers
faq
+ Issue reporting and resolution process <issue-triage-process>
Review comment:
I believe it is useful for both end users who report issues and want to understand the process of "what next", as well as for contributors.
I do think adding this link to the CONTRIBUTING.rst also makes sense, once this is reviewed and published.
----------------------------------------------------------------
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
[GitHub] [airflow] vikramkoka commented on a change in pull request #14223: Added Issue reporting and triage process document
Posted by GitBox <gi...@apache.org>.
vikramkoka commented on a change in pull request #14223:
URL: https://github.com/apache/airflow/pull/14223#discussion_r578668559
##########
File path: docs/apache-airflow/issue-triage-process.rst
##########
@@ -0,0 +1,195 @@
+ .. 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.
+
+
+
+
+Issue reporting and resolution process
+======================================
+
+This document explains the issue tracking and triage process within Apache
+Airflow including labels, milestones, and priorities as well as the process
+of resolving issues.
+
+Labels
+''''''
+
+Since Apache Airflow uses Github Issues as the issue tracking system, the
+use of labels is extensive. Though issue labels tend to change over time
+based on components within the project, the majority of the ones listed
+below should stand the test of time.
+
+The intention with the use of labels with the Apache Airflow project is
+that they should ideally be non-temporal in nature and primarily used
+to indicate the following elements:
+
+**Kind**
+
+The “kind” labels indicate “what kind of issue it is”. The most
+commonly used “kind” labels are: bug, feature, documentation, or task.
+
+Therefore, when reporting an issue, the label of ``kind:bug`` is to
+indicate a problem with the functionality, whereas the label of
+``kind:feature`` is a desire to extend the functionality.
+
+There has been discussion within the project about whether to separate
+the desire for “new features” from “enhancements to existing features”,
+but in practice most “feature requests” are actually enhancement requests,
+so we decided to combine them both into ``kind:feature``.
+
+We recently introduced ``kind:task`` to categorize issues which are
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
[GitHub] [airflow] potiuk commented on a change in pull request #14223: Added Issue reporting and triage process document
Posted by GitBox <gi...@apache.org>.
potiuk commented on a change in pull request #14223:
URL: https://github.com/apache/airflow/pull/14223#discussion_r577836682
##########
File path: docs/apache-airflow/issue-triage-process.rst
##########
@@ -0,0 +1,195 @@
+ .. 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.
+
+
+
+
+Issue reporting and resolution process
+======================================
+
+This document explains the issue tracking and triage process within Apache
+Airflow including labels, milestones, and priorities as well as the process
+of resolving issues.
+
+Labels
+''''''
+
+Since Apache Airflow uses Github Issues as the issue tracking system, the
+use of labels is extensive. Though issue labels tend to change over time
+based on components within the project, the majority of the ones listed
+below should stand the test of time.
+
+The intention with the use of labels with the Apache Airflow project is
+that they should ideally be non-temporal in nature and primarily used
+to indicate the following elements:
+
+**Kind**
+
+The “kind” labels indicate “what kind of issue it is”. The most
+commonly used “kind” labels are: bug, feature, documentation, or task.
+
+Therefore, when reporting an issue, the label of ``kind:bug`` is to
+indicate a problem with the functionality, whereas the label of
+``kind:feature`` is a desire to extend the functionality.
+
+There has been discussion within the project about whether to separate
+the desire for “new features” from “enhancements to existing features”,
+but in practice most “feature requests” are actually enhancement requests,
+so we decided to combine them both into ``kind:feature``.
+
+We recently introduced ``kind:task`` to categorize issues which are
+identified elements of work to be done, primarily as part of a larger
+change to be done as part of an AIP or something which needs to be cleaned
+up in the project.
+
+Issues of ``kind:documentation`` are for changes which need to be
+made to the documentation within the project.
+
+
+**Area**
+
+The “area” set of labels should indicate the component of the code
+referenced by the issue. At a high level, the biggest areas of the project
+are: Airflow Core and Airflow Providers, which are referenced by ``area:core``
+and ``area:providers``. This is especially important since these are now
+being released and versioned independently.
+
+There are more detailed areas of the project such as Scheduler, Webserver,
+API, UI, Logging, and Kubernetes, which are all conceptually under the
+“Airflow Core” area of the project.
+
+Similarly, some providers are broken out such as Apache (``provider/Apache``),
+AWS (``provider/AWS``), Azure (``provider/Azure``), and Google (``provider/Google``).
+These make it easier for developers working on a single provider to
+track issues for that provider.
+
+Most issues need a combination of "kind" and "area" labels to be actionable.
+For example:
+
+* Feature request for an additional API would have ``kind:feature`` and ``area:API``
+* Bug report on the User Interface would have ``kind:bug`` and ``area:UI``
+* Documentation request on the Kubernetes Executor, would have ``kind:documentation`` and ``area:kubernetes``
+
+
+Response to issues
+''''''''''''''''''
+
+Once an issue has been created on the Airflow project, someone from the
+Airflow team or the Airflow community typically responds to this issue.
+This response can have multiple elements.
+
+**Priority**
+
+After significant discussion about the different priority schemes currently
+being used across various projects, we decided to use a priority scheme based
+on the Kubernetes project, since the team felt it was easier for people to
+understand.
+
+Therefore, the priority labels used are:
+
+* ``priority:critical``: Showstopper bug that should be resolved immediately and a patch issued as soon as possible. Typically, this is because it affects most users and would take down production systems.
+* ``priority:high``: A high priority bug that affects many users and should be resolved quickly, but can wait for the next scheduled patch release.
+* ``priority:medium``: A bug that should be fixed before the next release, but would not block a release if found during the release process.
+* ``priority:low``: A bug with a simple workaround or a nuisance that does not stop mainstream functionality.
+
+
+It's important to use priority labels effectively so we can triage incoming issues
+appropriately and make sure that when we release a new version of Airflow,
+we can ship a release confident that there are no “production blocker” issues in it.
Review comment:
I believe yeah, this might trigger us to have an out-of-band release in case we find a critical issue - especially that we can do it easily now and nothing stops us except the efficiency/batching of voting process.
----------------------------------------------------------------
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
[GitHub] [airflow] vikramkoka commented on a change in pull request #14223: Added Issue reporting and triage process document
Posted by GitBox <gi...@apache.org>.
vikramkoka commented on a change in pull request #14223:
URL: https://github.com/apache/airflow/pull/14223#discussion_r576483331
##########
File path: docs/apache-airflow/issue-triage-process.rst
##########
@@ -0,0 +1,195 @@
+ .. 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.
+
+
+
+
+Issue reporting and resolution process
+======================================
+
+This document explains the issue tracking and triage process within Apache
+Airflow including labels, milestones, and priorities as well as the process
+of resolution of issues.
+
+Labels
+''''''
+
+Since Apache Airflow uses Github Issues as the issue tracking system, the
+use of labels is extensive. Though issue labels tend to change over time
+based on components within the project, the majority of the ones listed
+below should stand the test of time.
+
+The intention with the use of labels with the Apache Airflow project is
+that they should ideally be non-temporal in nature and primarily used
+to indicate the following elements:
+
+**Kind**
+
+The “kind” of labels indicate “what kind of issue it is”. The most
+commonly used “kind” labels are: bug, feature, documentation, or task.
+
+Therefore, when reporting an issue, the label of ``kind:bug`` is to
+indicate a problem with the functionality, whereas the label of
+``kind:feature`` is a desire to extend the functionality.
+
+There has been discussion within the project about whether to separate
+the desire for “new features” from “enhancements to existing features”,
+but in practice most “feature requests” are actually enhancement requests,
+so we decided to combine them both into ``kind:feature``.
+
+We recently introduced ``kind:task`` to categorize issues which are
+identified elements of work to be done, primarily as part of a larger
+change to be done as part of an AIP or something which needs to be cleaned
+up in the project.
+
+Issues of ``kind:documentation`` are exactly that, changes which need to be
+made to the documentation within the project.
+
+
+**Area**
+
+The “area” set of labels should indicate the component of the code
+referenced by the issue. At a high level, the biggest areas of the project
+are: Airflow Core and Airflow Providers, which are referenced by ``area:core``
+and ``area:providers``. This is especially important since these are now
+being released and versioned independently.
+
+There are more detailed areas of the project such as Scheduler, Webserver,
+API, UI, Logging, and Kubernetes which are all conceptually under the
+“Airflow Core” area of the project.
+
+Similarly, some providers are broken out such as Apache (``provider/Apache``),
+AWS (``provider/AWS``), Azure (``provider/Azure``), and Google (``provider/Google``).
+These make it easier for developers working on a single provider to
+track issues for that provider.
+
+Most issues need a combination of "kind" and "area" labels to be actionable.
+For example:
+
+* Feature request for an additional API would have ``kind:feature`` and ``area:API``
+* Bug report on the User Interface would have ``kind:bug`` and ``area:UI``
+* Documentation request on the Kubernetes Executor, would have ``kind:documentation`` and ``area:kubernetes``
+
+
+Response to issues
+''''''''''''''''''
+
+Once an issue has been created on the Airflow project, someone from the
+Airflow team or the Airflow community typically responds to this issue.
+This response can have multiple elements.
+
+**Priority**
+
+After significant discussion about the different priority schemes currently
+being used across various projects, we decided to use a priority scheme based
+on the Kubernetes project, since the team felt it was easier for people to
+understand.
+
+Therefore, the priority labels used are:
+
+* ``Priority:critical``: Showstopper bug that should be resolved immediately and a patch issued as soon as possible. Typically, this is because it affects most users and would take down production systems.
Review comment:
You are right, it should have been lower case. Fixed 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
[GitHub] [airflow] vikramkoka commented on a change in pull request #14223: Added Issue reporting and triage process document
Posted by GitBox <gi...@apache.org>.
vikramkoka commented on a change in pull request #14223:
URL: https://github.com/apache/airflow/pull/14223#discussion_r578823242
##########
File path: docs/apache-airflow/index.rst
##########
@@ -104,6 +104,7 @@ unit of work and continuity.
production-deployment
backport-providers
faq
+ Issue reporting and resolution process <issue-triage-process>
Review comment:
Got it.
I removed the change to the documentation index and moved this new .rst file to the top level directory.
I added a reference to it in CONTRIBUTING.rst
----------------------------------------------------------------
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
[GitHub] [airflow] vikramkoka commented on a change in pull request #14223: Added Issue reporting and triage process document
Posted by GitBox <gi...@apache.org>.
vikramkoka commented on a change in pull request #14223:
URL: https://github.com/apache/airflow/pull/14223#discussion_r578706332
##########
File path: docs/apache-airflow/issue-triage-process.rst
##########
@@ -0,0 +1,195 @@
+ .. 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.
+
+
+
+
+Issue reporting and resolution process
+======================================
+
+This document explains the issue tracking and triage process within Apache
+Airflow including labels, milestones, and priorities as well as the process
+of resolving issues.
+
+Labels
+''''''
+
+Since Apache Airflow uses Github Issues as the issue tracking system, the
+use of labels is extensive. Though issue labels tend to change over time
+based on components within the project, the majority of the ones listed
+below should stand the test of time.
+
+The intention with the use of labels with the Apache Airflow project is
+that they should ideally be non-temporal in nature and primarily used
+to indicate the following elements:
+
+**Kind**
+
+The “kind” labels indicate “what kind of issue it is”. The most
+commonly used “kind” labels are: bug, feature, documentation, or task.
+
+Therefore, when reporting an issue, the label of ``kind:bug`` is to
+indicate a problem with the functionality, whereas the label of
+``kind:feature`` is a desire to extend the functionality.
+
+There has been discussion within the project about whether to separate
+the desire for “new features” from “enhancements to existing features”,
+but in practice most “feature requests” are actually enhancement requests,
+so we decided to combine them both into ``kind:feature``.
+
+We recently introduced ``kind:task`` to categorize issues which are
+identified elements of work to be done, primarily as part of a larger
+change to be done as part of an AIP or something which needs to be cleaned
+up in the project.
+
+Issues of ``kind:documentation`` are for changes which need to be
+made to the documentation within the project.
+
+
+**Area**
+
+The “area” set of labels should indicate the component of the code
+referenced by the issue. At a high level, the biggest areas of the project
+are: Airflow Core and Airflow Providers, which are referenced by ``area:core``
+and ``area:providers``. This is especially important since these are now
+being released and versioned independently.
+
+There are more detailed areas of the project such as Scheduler, Webserver,
+API, UI, Logging, and Kubernetes, which are all conceptually under the
+“Airflow Core” area of the project.
+
+Similarly, some providers are broken out such as Apache (``provider/Apache``),
+AWS (``provider/AWS``), Azure (``provider/Azure``), and Google (``provider/Google``).
+These make it easier for developers working on a single provider to
+track issues for that provider.
+
+Most issues need a combination of "kind" and "area" labels to be actionable.
+For example:
+
+* Feature request for an additional API would have ``kind:feature`` and ``area:API``
+* Bug report on the User Interface would have ``kind:bug`` and ``area:UI``
+* Documentation request on the Kubernetes Executor, would have ``kind:documentation`` and ``area:kubernetes``
+
+
+Response to issues
+''''''''''''''''''
+
+Once an issue has been created on the Airflow project, someone from the
+Airflow team or the Airflow community typically responds to this issue.
+This response can have multiple elements.
+
+**Priority**
+
+After significant discussion about the different priority schemes currently
+being used across various projects, we decided to use a priority scheme based
+on the Kubernetes project, since the team felt it was easier for people to
+understand.
+
+Therefore, the priority labels used are:
+
+* ``priority:critical``: Showstopper bug that should be resolved immediately and a patch issued as soon as possible. Typically, this is because it affects most users and would take down production systems.
+* ``priority:high``: A high priority bug that affects many users and should be resolved quickly, but can wait for the next scheduled patch release.
+* ``priority:medium``: A bug that should be fixed before the next release, but would not block a release if found during the release process.
+* ``priority:low``: A bug with a simple workaround or a nuisance that does not stop mainstream functionality.
+
+
+It's important to use priority labels effectively so we can triage incoming issues
+appropriately and make sure that when we release a new version of Airflow,
+we can ship a release confident that there are no “production blocker” issues in it.
+
+
+**Milestones**
+
+The key temporal element in the issue triage process is the concept of milestones.
+This is critical for release management purposes and will be used represent upcoming
+release targets.
+
+Issues currently being resolved will get assigned to one of the upcoming releases.
+For example a feature request may be targeted for the next feature release milestone
+such as ``2.x``, where a bug may be targeted for the next patch release milestone
+such as ``2.x.y``.
+
+In the interest of being precise, when an issue is tagged with a milestone, it
+represents that it will be considered for that release, not that it is committed to
+a release. Once a PR is created to fix that issue and when that PR is tagged with a
+milestone, it implies that the PR is intended to released in that milestone.
+
+It is worth noting that Airflow Core and Airflow Providers are now released and
Review comment:
Done. I explicitly made the milestone reference only towards Airflow Core releases now. Can update this later once the Provider release proposal is locked down.
##########
File path: docs/apache-airflow/issue-triage-process.rst
##########
@@ -0,0 +1,195 @@
+ .. 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.
+
+
+
+
+Issue reporting and resolution process
+======================================
+
+This document explains the issue tracking and triage process within Apache
+Airflow including labels, milestones, and priorities as well as the process
+of resolving issues.
+
+Labels
+''''''
+
+Since Apache Airflow uses Github Issues as the issue tracking system, the
+use of labels is extensive. Though issue labels tend to change over time
+based on components within the project, the majority of the ones listed
+below should stand the test of time.
+
+The intention with the use of labels with the Apache Airflow project is
+that they should ideally be non-temporal in nature and primarily used
+to indicate the following elements:
+
+**Kind**
+
+The “kind” labels indicate “what kind of issue it is”. The most
+commonly used “kind” labels are: bug, feature, documentation, or task.
+
+Therefore, when reporting an issue, the label of ``kind:bug`` is to
+indicate a problem with the functionality, whereas the label of
+``kind:feature`` is a desire to extend the functionality.
+
+There has been discussion within the project about whether to separate
+the desire for “new features” from “enhancements to existing features”,
+but in practice most “feature requests” are actually enhancement requests,
+so we decided to combine them both into ``kind:feature``.
+
+We recently introduced ``kind:task`` to categorize issues which are
+identified elements of work to be done, primarily as part of a larger
+change to be done as part of an AIP or something which needs to be cleaned
+up in the project.
+
+Issues of ``kind:documentation`` are for changes which need to be
+made to the documentation within the project.
+
+
+**Area**
+
+The “area” set of labels should indicate the component of the code
+referenced by the issue. At a high level, the biggest areas of the project
+are: Airflow Core and Airflow Providers, which are referenced by ``area:core``
+and ``area:providers``. This is especially important since these are now
+being released and versioned independently.
+
+There are more detailed areas of the project such as Scheduler, Webserver,
+API, UI, Logging, and Kubernetes, which are all conceptually under the
+“Airflow Core” area of the project.
+
+Similarly, some providers are broken out such as Apache (``provider/Apache``),
Review comment:
tried again, please let me know if this is better.
----------------------------------------------------------------
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