josh-fell commented on code in PR #36197:
URL: https://github.com/apache/airflow/pull/36197#discussion_r1425530964
##########
.github/ISSUE_TEMPLATE/airflow_bug_report.yml:
##########
@@ -31,17 +31,26 @@ body:
- "Other Airflow 2 version (please specify below)"
validations:
required: true
+ - type: input
+ attributes:
+ label: If "Other Airflow 2 version" selected, which one?
Review Comment:
Absolutely. My thinking was to try and short-circuit that response for the
triage team and maintainers and add even more encouragement, in a second note,
to please reproduce on a recent Airflow version if the author knows it's an
older one.
I'm thinking about these scenarios:
1. Nowhere in the details is an Airflow version specified (either being
well- or sparsely-documented).
- Someone trying to triage the issue has to ask the author what version
they were on and await a response. The version they are using could be the
previous patch version or a few minor versions old; we don't know. The former
makes it far more reasonable to address than the latter.
2. The Airflow version used is buried within _any_ of the other fields.
- Now someone needs to read most of the issue to find out they are on a
version that is a year old.
In both cases, it would be nice to know, upfront, what the version is to
either continue reading and asses how compelling the issue is, or immediately
ask the author to attempt to reproduce on a recent version. Since this new
field is at the beginning of the form, If this field isn't specified when
"Other Airflow 2 version" is selected, then the triage approach could be to
immediately ask to reproduce as well.
Maybe I'm wrong about adding speed for triaging, but more folks continue to
use Airflow (which is fantastic) and more non-trivial functionality is getting
added (again, fantastic) which means more issues will be logged. Putting a
little bit more onus on the issue author and providing a little more context
for a "triager" to act upon.
--
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.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
