This is an automated email from the ASF dual-hosted git repository.
potiuk pushed a commit to branch main
in repository https://gitbox.apache.org/repos/asf/airflow.git
The following commit(s) were added to refs/heads/main by this push:
new c185752b1a Strenghten a bit and clarify importance of triaging issues
(#27262)
c185752b1a is described below
commit c185752b1aee040ee3d4a7eb5ab41ca40a57e5c3
Author: Jarek Potiuk <[email protected]>
AuthorDate: Sun Nov 6 17:16:46 2022 +0100
Strenghten a bit and clarify importance of triaging issues (#27262)
Triaging issues is an important part of the work we do. It is crucial
that we respond swiftly and accurately to issues and discussions
created by our users so that they feel welcome and listened to.
By participation in triaging process, contributors might show not
only their willingness of helping other community members, but also
show that they understand various parts of airflow (also that they
are capable of learning it while helping others - which is one of
the best ways to learn parts of Airflow you do not actively
contribute to.
---
.github/ISSUE_TEMPLATE/feature_request.yml | 24 ++++--
COMMITTERS.rst | 7 +-
ISSUE_TRIAGE_PROCESS.rst | 123 +++++++++++++++++++++++++----
3 files changed, 132 insertions(+), 22 deletions(-)
diff --git a/.github/ISSUE_TEMPLATE/feature_request.yml
b/.github/ISSUE_TEMPLATE/feature_request.yml
index 388b7d19a5..837a88f698 100644
--- a/.github/ISSUE_TEMPLATE/feature_request.yml
+++ b/.github/ISSUE_TEMPLATE/feature_request.yml
@@ -12,9 +12,21 @@ body:
We really appreciate the community efforts to improve Airflow.
- Note, that you do not need to create an issue if you have a change
ready to submit!
-
+ Features should be small improvements that do not dramatically change
Airflow assumptions.
+ Note, that in this case you do not even need to create an issue if you
have a code change ready to submit!
You can open [Pull Request](https://github.com/apache/airflow/pulls)
immediately instead.
+
+ For bigger features, those that are impacting Airflow's architecture,
security assumptions,
+ backwards compatibility etc. should be discussed in the [airflow
devlist](https://lists.apache.org/[email protected]).
+ Such features will need initial discussion - possibly in
[discussion](https://github.com/apache/airflow/discussions), followed by
+ [Airflow Improvement
Proposal](https://cwiki.apache.org/confluence/display/AIRFLOW/Airflow+Improvement+Proposals)
and formal voting.
+ If you want to introduce such feature, you need to be prepared to lead
a discussion, get consensus
+ among the community and eventually conduct a successful
+ [vote](https://www.apache.org/foundation/voting.html) in the community.
+
+ If unsure - open a
[discussion](https://github.com/apache/airflow/discussions) first to gather
+ an initial feedback on your idea.
+
<br clear='left'/>"
# yamllint enable rule:line-length
@@ -37,10 +49,12 @@ body:
attributes:
label: Are you willing to submit a PR?
description: >
- This is absolutely not required, but we are happy to guide you in the
contribution process
- especially if you already have a good understanding of how to
implement the feature.
+ If want to submit a PR you do not need to open feature request,
<b>just create the PR!</b>.
+ Especially if you already have a good understanding of how to
implement the feature.
Airflow is a community-managed project and we love to bring new
contributors in.
- Find us in #airflow-how-to-pr on Slack!
+ Find us in #airflow-how-to-pr on Slack! It's optional though - if you
have good idea for small
+ feature, others might implement it if they pick an interest in it, so
feel free to leave that
+ checkbox unchecked.
options:
- label: Yes I am willing to submit a PR!
- type: checkboxes
diff --git a/COMMITTERS.rst b/COMMITTERS.rst
index d90bd23e19..5b8a942503 100644
--- a/COMMITTERS.rst
+++ b/COMMITTERS.rst
@@ -75,9 +75,10 @@ Code contribution
Community contributions
^^^^^^^^^^^^^^^^^^^^^^^^
-1. Was instrumental in triaging issues
-2. Improved documentation of Airflow in significant way
-3. Lead change and improvements introduction in the "community" processes and
tools
+1. Actively participates in `triaging issues <ISSUE_TRIAGE_PROCESS.rst>`_
showing their understanding
+ of various areas of Airflow and willingness to help other community
members.
+2. Improves documentation of Airflow in significant way
+3. Leads/implements changes and improvements introduction in the "community"
processes and tools
4. Actively spreads the word about Airflow, for example organising Airflow
summit, workshops for
community members, giving and recording talks, writing blogs
5. Reporting bugs with detailed reproduction steps
diff --git a/ISSUE_TRIAGE_PROCESS.rst b/ISSUE_TRIAGE_PROCESS.rst
index 76d65dc50a..ef79a0276e 100644
--- a/ISSUE_TRIAGE_PROCESS.rst
+++ b/ISSUE_TRIAGE_PROCESS.rst
@@ -15,9 +15,6 @@
specific language governing permissions and limitations
under the License.
-
-
-
Issue reporting and resolution process
======================================
@@ -27,16 +24,115 @@ of resolving issues.
An unusual element of the Apache Airflow project is that you can open a PR
to fix an issue or make an enhancement, without needing to open an issue first.
-This is intended to make it as easy as possible to contribute to
-the project.
+This is intended to make it as easy as possible to contribute to the project.
+
+Usually users are report `Issues <https://github.com/apache/airflow/issues>`_
where they describe
+the issues they think are Airflow issues and should be solved. There are two
kinds of issues:
+
+* Bugs - when the user thinks the reported issue is a bug in Airflow
+* Features - when there are small features that the user would like to see in
Airflow
+
+We have `templates
<https://github.com/apache/airflow/tree/main/.github/ISSUE_TEMPLATE>`_ for both
types
+of issues defined in Airflow.
+
+However, important part of our issue reporting process are
+`GitHub Discussions <https://github.com/apache/airflow/discussions>`_ . Issues
should represent
+clear, small feature requests or reproducible bugs which can/should be either
implemented or fixed.
+Users are encouraged to open discussions rather than issues if there are no
clear, reproducible
+steps, or when they have troubleshooting problems, and one of the important
points of issue triaging is
+to determine if the issue reported should be rather a discussion. Converting
an issue to a discussion
+while explaining the user why is an important part of triaging process.
+
+Responding to issues/discussions (relatively) quickly
+'''''''''''''''''''''''''''''''''''''''''''''''''''''
+
+It is vital to provide rather quick feedback to issues and discussions opened
by our users, so that they
+feel listened to rather than ignored. Even if the response is "we are not
going to work on it because ...",
+or "converting this issue to discussion because ..." or "closing because it is
a duplicate of #xxx", it is
+far more welcoming than leaving issues and discussions unanswered. Sometimes
issues and discussions are
+answered by other users (and this is cool) but if an issue/discussion is not
responded to for a few days or
+weeks, this gives an impression that the user was ignored and that the Airflow
project is unwelcoming.
+
+We strive to provide relatively quick responses to all such issues and
discussions. Users should exercise
+patience while waiting for those (knowing that people might be busy, on
vacations etc.) however they should
+not wait weeks until someone looks at their issues.
+
+
+Issue Triage Team
+''''''''''''''''''
+
+While many of the issues can be responded to by other users and committers,
the committer team is not
+big enough to handle all such requests and sometimes they are busy with
implementing important
+Therefore, some people who are regularly contributing and helping other users
and shown their deep interest
+in the project can be invited to join the triage team.
+`the .asf.yaml <.asf.yaml>`_ file in the ``collaborators`` section.
+
+Committers can invite people to become members of the triage team if they see
that the users are already
+helping and responding to issues and when they see the users are involved
regularly. But you can also ask
+to become a member of the team (on devlist) if you can show that you have done
that and when you want to have
+more ways to help others.
+
+The triage team members do not have committer privileges but they can
+assign, edit, and close issues and pull requests without having capabilities
to merge the code. They can
+also convert issues into discussions and back. The expectation for the issue
triage team is that they
+spend a bit of their time on those efforts. Triaging means not only assigning
the labels but often responding
+to the issues and answering user concerns or if additional input is needed -
tagging the committers or other community members who might be able to help
provide more complete answers.
+
+Being an active and helpful member of the "Issue Triage Team" is actually one
of the paths towards
+becoming a committer. By actively helping the users, triaging the issues,
responding to them and
+involving others (when needed) shows that you are not only willing to help our
users and the community,
+but are also ready to learn about parts of the projects you are not actively
contributing to - all of that
+are super valuable components of being eligible to `become a committer
<COMMITTERS.md>`_.
+
+If you are a member of the triage team and not able to make any commitment,
it's best to ask to have yourself
+removed from the triage team.
+
+BTW. Every committer is pretty much automatically part of the "Issue Triage
Team" - so if you are committer,
+feel free to follow the process for every issue you stumble upon.
+
+Actions that can be taken by the issue triager
+''''''''''''''''''''''''''''''''''''''''''''''
+
+There are several actions an issue triager might take:
+
+* Closing and issue with "invalid" label explaining why it is closed in case
the issue is invalid. This
+ should be accompanied by information that we can always re-open an issue if
our understanding was wrong
+ or if the user provides more information.
+
+* Converting an issue to a discussion, if it is not very likely it is an
Airflow issue or when it is not
+ responsible, or when it is a bigger feature proposal requiring discussion or
when it's really users
+ troubleshooting or when the issue description is not at all clear. This also
involves inviting the user
+ to a discussion if more information might change it.
+
+* Assigning the issue to a milestone, if the issue seems important enough that
it should likely be looked
+ at before the next release but there is not enough information or doubts on
why and what can be fixed.
+ Usually we assign to the the next bugfix release - then, no matter what the
issue will be looked at
+ by the release manager and it might trigger additional actions during the
release preparation.
+ This is usually followed by one of the actions below.
+
+* Fixing the issue in a PR if you see it is easy to fix. This is a great way
also to learn and
+ contribute to parts that you usually are not contributing to, and sometimes
it is surprisingly easy.
+
+* Assigning "good first issue" label if an issue is clear but not important to
be fixed immediately, This
+ often lead to contributors picking up the issues when they are interested.
This can be followed by assigning
+ the user who comments "I want to work on this" in the issue (which is most
welcome).
+
+* Asking the user for additional information if it is needed to perform
further investigations. This should
+ be accompanied by assigning ``pending response`` label so that we can
clearly see the issues that need
+ extra information.
+
+* Calling other people who might be knowledgeable in the area by @-mentioning
them in a comment.
+
+* Assigning other labels to the issue as described below.
+
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.
+Since Apache Airflow uses "GitHub Issues" and "Github Discussions" as the
+issue tracking systems, 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
@@ -94,7 +190,6 @@ For example:
* 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
''''''''''''''''''
@@ -208,7 +303,7 @@ following situations:
**GitHub Discussions**
Issues should represent clear feature requests which can/should be
implemented. If the idea is vague or can be solved with easier steps
-we normally convert such issues to Discussions in the Ideas category.
-Issues that seems more like support requests are also converted to Discussions
in the Q&A category.
-We use judgment about which Issues to convert to Discussions, it's best to
always clarify with a comment why the Issue is being converted.
-Note that we can always convert Discussions back to Issues.
+we normally convert such issues to discussions in the Ideas category.
+Issues that seems more like support requests are also converted to discussions
in the Q&A category.
+We use judgment about which Issues to convert to discussions, it's best to
always clarify with a comment why the issue is being converted.
+Note that we can always convert discussions back to issues.
