[GitHub] [airflow] potiuk commented on a change in pull request #14223: Added Issue reporting and triage process document

[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