Clarify assignment policy for issues

[potiuk]

Those changes describe the way we change our approach for assigning issues and explaining why we are doing it.

---

Was generative AI tooling used to co-author this PR?

• Yes (please specify the tool below)

Generated-by: Copilot and Gemiini to correct grammar, apply better structure and reflow the rst following the guidelines

---

• Read the Pull Request Guidelines for more information. Note: commit author/co-author name and email in commits become permanently public when merged.
• For fundamental code changes, an Airflow Improvement Proposal (AIP) is needed.
• When adding dependency, check compliance with the ASF 3rd Party License Policy.
• For significant user-facing changes create newsfragment: {pr_number}.significant.rst or {issue_number}.significant.rst, in airflow-core/newsfragments.

[pierrejeambrun]

Overall LGTM, just one nit beside @aritra24 comment

[guan404ming]

Thanks!

[gyli]

Good to see the issue assignment change!

[Miretpl]

Just small nits, generally LGTM

[jscheffl]

Cool!

[shahar1]

Thanks for working on that!
I'd appreciate if you could address my comments before merging.

[shahar1]

tl;dr/post-writing comment:
If this line is intended only at "uncertain bugs", please clarify it (otherwise, please read the long part). Also, if we plan to use the GitHub discussions more extensively, all maintainers/triagers should be aligned.

---

I don't feel comfortable with this specific
statement.

When people indicate a real reproducible bug or have a valid feature request, I don't see a reason to first consider doing it within a GitHub discussion - as it is not intended for that purpose and will be harder to track. Also, currently GitHub discussions is a blind spot for most maintainers as well.
If it's "something that seems like a bug, but uncertain" - then maybe GitHub discussions is a more suitable for that, but I didn't get the impression from the discussion on dev list that committers/triagers are well-aware that this section should be on their radar from now on.

What I think that should be done instead, considering the context of the discussion on the dev. thread list:

1. We should be stricter with the requirement for reproduction steps when reporting bugs, and refer non-reproducible ones to the discussion section.
2. If we do want to encourage usage of GitHub discussions, for whatever purpose, it should be clarified for maintainers/triagers that they should track it as well.

[vatsrahul1001]

Yeah, I agree with @shahar1 on this. If it’s a reproducible bug, users should go ahead and create an issue with clear steps to reproduce. In the case of a new feature request, or if they’re not sure whether it’s a bug, we should use GitHub Discussions instead of creating issues.

[Lee-W]

Maybe something like if you're not sure whether it's a bug or a feature, start with creating a GitHub Discussion?

In my ideal scenario, we should create issues solely for tracking confirmed features and bugs. All the discussion should happen in GitHub Discussions. However, that's not something we have today. We'll need to decide whether we want to educate contributors (and maintainers as well) to do things this way

[potiuk]

I softened it quite a bit - in the way that @Lee-W proposed. Stressing the need for reproducible case for issue to open (and we already have mandatory "How to reproduce" in the issue

airflow/.github/ISSUE_TEMPLATE/1-airflow_bug_report.yml

Line 72 in 98ad78f

dragging and dropping them here.

And yes we might want to discuss (pun intended) use of discussions in the project, but I do not see it as a very necesary thing to be much more "active" for them - many of the discussions are where different people discuss things - not necessarily maintainers. I see discussions as the place where the wider community might discuss things - with or without maintainers. There is no particularly strong need for maintainers to review and participate in all the discussions happening there - it's clear that no decisions are made there and that important topic should be brought to devlist.

Of course - it would be nice to have more maintainers actively participating there, and we should encourage them - but we should refrain from thinking that maintainers are "necessary" in all discussions happening there.

[potiuk]

@shahar1 @vatsrahul1001 @Lee-W -> let me know if the new wording looks good for you and whether the concerns are responded to - and resolve it if they are :)

[Lee-W]

looks good to me :)

[pankajkoti]

Nice clarity on the upcoming way of assigning issues!