Skip to content

Commit 0154d8e

Browse files
potiukpotiuk
authored
Clarify assignment policy for issues (#62417)
Those changes describe the way we change our approach for assigning issues and explaining why we are doing it.
1 parent 25c0eb5 commit 0154d8e

File tree

1 file changed

+93
-34
lines changed

1 file changed

+93
-34
lines changed

‎contributing-docs/04_how_to_contribute.rst‎

Lines changed: 93 additions & 34 deletions
Original file line numberDiff line numberDiff line change
@@ -36,53 +36,111 @@ Report security issues
3636
If you want to report a security finding, please follow the
3737
`Security policy <https://github.com/apache/airflow/security/policy>`_
3838

39+
Issue reporting and resolution process
40+
======================================
41+
42+
.. note::
43+
**TL;DR: Quick Summary**
44+
45+
* **No Issue Needed:** You can open a PR directly without opening an issue first.
46+
* **Discussion First:** If you aren't sure about a bug or feature, start a
47+
`GitHub Discussion <https://github.com/apache/airflow/discussions>`_ instead.
48+
* **No Assignments:** we do **not** assign issues to non-maintainers or people who maintainer did not
49+
reach out about the issue. Please do not ask to be assigned; simply comment "working on it" and
50+
submit your PR.
51+
* **Parallel Work is fine:** Multiple people can work on the same issue and it's fine while not necessarily
52+
default. When it happens - we will merge the best implementation, and encourage learning and
53+
community feedback.
54+
55+
An unusual element of the Apache Airflow project (compared, for example, to commercial
56+
development) is that you can open a PR to fix an issue or make an enhancement without needing
57+
to open an issue first. This is intended to make it as easy as possible to contribute to the
58+
project.
59+
60+
If you're not sure whether it's a bug or a feature, consider starting
61+
with a `GitHub Discussion <https://github.com/apache/airflow/discussions>`_ instead.
62+
63+
If you have a significant topic to discuss where important behaviour of Airflow seems like a bug
64+
or needs an improvement, start a thread on the
65+
`Devlist <https://lists.apache.org/list.html?dev@airflow.apache.org>`_ instead.
3966

40-
Fix Bugs
41-
--------
67+
The Apache Airflow project uses a set of labels for tracking and triaging issues, as well as
68+
a set of priorities and milestones to track how and when enhancements and bug fixes make it
69+
into an Airflow release. This is documented as part of the
70+
`Issue reporting and resolution process <../ISSUE_TRIAGE_PROCESS.rst>`_.
4271

43-
Look through the GitHub issues for bugs. Anything is open to whoever wants to implement it.
72+
Contribute code changes
73+
-----------------------
4474

75+
Note that we do not usually assign issues to people. Maintainers only self-assign issues when
76+
they want to ensure they are working on something where they have unique knowledge or a
77+
specific desire to work on a specific part.
4578

46-
Issue reporting and resolution process
47-
--------------------------------------
48-
49-
An unusual element of the Apache Airflow project is that you can open a PR to
50-
fix an issue or make an enhancement, without needing to open an issue first.
51-
This is intended to make it as easy as possible to contribute to the project.
52-
53-
If you however feel the need to open an issue (usually a bug or feature request)
54-
consider starting with a `GitHub Discussion <https://github.com/apache/airflow/discussions>`_ instead.
55-
In the vast majority of cases discussions are better than issues - you should only open
56-
issues if you are sure you found a bug and have a reproducible case,
57-
or when you want to raise a feature request that will not require a lot of discussion.
58-
If you have a very important topic to discuss, start a discussion on the
59-
`Devlist <https://lists.apache.org/list.html?dev@airflow.apache.org>`_ instead.
79+
Starting **March 2026**, we do not expect people to ask to be assigned to issues, and we will
80+
not assign them even if asked. Contributors are still welcome to work on those issues and comment
81+
that they are "working on it", but we will not formally assign them. We used this system
82+
previously, but found it did not work well in a landscape where:
83+
84+
* Users treat assignment as a "badge".
85+
* Users are unsure if they can follow through on the work.
86+
* Users attempt to use Gen-AI to solve the issue and fail to deliver or lose interest.
87+
88+
Consequently, we do not assign issues to anyone who is not a maintainer, unless a maintainer
89+
knows them personally and has agreed to the work via direct communication - this requires
90+
maintainer to actively reach out to the person before, you should not ask to be assigned.
91+
92+
The "no assignment" policy is not intended to discourage contributors — quite the opposite. We
93+
want to ensure we do not have a backlog of "assigned" issues that are not actually being
94+
addressed. **This often prevents others from working on them if they want.**
95+
96+
Working in parallel on the same issue is fine, but not the default. When this leads to
97+
several PRs fixing the same issue, we will merge the best implementation and close the others,
98+
and we encourage cooperation and learning from each other in the process. This is a positive outcome,
99+
as it allows contributors to:
100+
101+
1. Receive feedback on their implementation.
102+
2. Learn from different perspectives and coding styles.
103+
3. Foster community building.
104+
105+
Any feature or bug request is open to whoever wants to address it, even if someone else has
106+
already commented or submitted a linked PR. If you wish to contribute to an issue that already
107+
has an open PR, you are encouraged to review that PR and help lead it to completion. However,
108+
it is also perfectly fine to submit your own PR if your solution is different. We embrace this
109+
"better PR wins" approach as the most effective way to encourage learning and ensure the best
110+
result for the project.
111+
112+
Fix Bugs
113+
........
114+
115+
Look through the `GitHub issues labeled "kind:bug" <https://github.com/apache/airflow/labels/kind%3Abug>`__
116+
for bugs.
60117

61-
The Apache Airflow project uses a set of labels for tracking and triaging issues, as
62-
well as a set of priorities and milestones to track how and when the enhancements and bug
63-
fixes make it into an Airflow release. This is documented as part of
64-
the `Issue reporting and resolution process <../ISSUE_TRIAGE_PROCESS.rst>`_,
118+
Anything is open to whoever wants to implement it. Easy to fix bugs are usually marked with the
119+
``good first issue`` label, but you can also look for other issues that are not marked as ``good first issue``
120+
- they might be still easy to fix, and they might be a good way
121+
to get started with the project.
65122

66123
Implement Features
67-
------------------
124+
..................
68125

69-
Look through the `GitHub issues labeled "kind:feature"
70-
<https://github.com/apache/airflow/labels/kind%3Afeature>`__ for features.
126+
Look through the `GitHub issues labeled "kind:feature" <https://github.com/apache/airflow/labels/kind%3Afeature>`__
127+
for features.
71128

72-
Any unassigned feature request issue is open to whoever wants to implement it.
129+
Anything is open to whoever wants to implement it. Easy to implement features are usually marked with the
130+
``good first issue`` label, but you can also look for other issues that are not marked as ``good first issue``
131+
- they might be still easy to implement, and they might be a good way to get started with the project.
73132

74-
We've created the operators, hooks, macros and executors we needed, but we've
75-
made sure that this part of Airflow is extensible. New operators, hooks, macros
76-
and executors are very welcomed!
133+
We've created the operators, hooks, macros and executors we needed, but we've made sure that this part of
134+
Airflow (providers) is easily extensible. New operators, hooks, macros and executors are very welcome!
77135

78136
Improve Documentation
79137
---------------------
80138

81-
Airflow could always use better documentation, whether as part of the official
82-
Airflow docs, in docstrings, ``docs/*.rst`` or even on the web as blog posts or
83-
articles.
139+
Airflow could always use better documentation, whether as part of the official Airflow docs, in docstrings,
140+
``/docs/`` folders in the projects or even on the web as blog posts or articles.
84141

85-
See the `Docs README <https://github.com/apache/airflow/blob/main/docs/README.md>`__ for more information about contributing to Airflow docs.
142+
See the `Docs README <https://github.com/apache/airflow/blob/main/docs/README.md>`__ for more information
143+
about contributing to Airflow docs.
86144

87145
Submit Feedback
88146
---------------
@@ -93,8 +151,9 @@ If you are proposing a new feature:
93151

94152
- Explain in detail how it would work.
95153
- Keep the scope as narrow as possible to make it easier to implement.
96-
- Remember that this is a volunteer-driven project, and that contributions are
97-
welcome :)
154+
- Remember that this is a volunteer-driven project, and that contributions are welcome, and sometimes
155+
the fastest way to get a new feature implemented/bug fixed is to implement it yourself and submit a
156+
PR for it.
98157

99158
-------------------------------
100159

0 commit comments

Comments
 (0)