Here's Airflow vote thread (~2020): https://lists.apache.org/thread/s5nk0mgblkzq9jrqgrvp12yn4kmy0o7b here's the discussion: https://lists.apache.org/thread/6lfth3o4gzk3s891bcqy045z5gl4fs07
I believe draft PRs could avoid "DISCUS" threads that suck time from everybody and those DISCUSS threads add nothing to the code :-/ For instance, Julian has recently launched "Refactoring tests". I think it would be just fine if Julian pushed a draft of the intended changes, we just added +1 and went forward. Just to clarify: the whole idea of moving to GitHub issues for Calcite started when Apache JMeter team started a discussion regarding moving from Bugzilla to GitHub Issues. Currently, I think that JIRA for Calcite is like learned helplessness. Everybody knows "JIRA is required", however, nobody questions that. I do not say JIRA is bad. I just say 99% of code changes happen in GitHub, so unifying issues and PRs would be a big plus. ---- Airflow team mentions that having a JIRA issue for each PR adds unnecessary overhead. I believe in many cases we could be just fine if we have everything right in the PR itself. For example, do we really need to create JIRA issues like "[CALCITE-4836] Upgrade protobuf-java 3.6.1 -> 3.17.1"? I believe filing a PR is just enough In many cases, having a proper comment in PR helps *A LOT* for the reviewer. https://github.com/apache/calcite/pull/2615 is a perfect example. PR 2615 does have a description that clarifies the reason for the change. It is just fine without JIRA. In many cases, I tend to copy descriptions between JIRA and PR because it does help for the review: it is much faster to switch between "conversation" and "files changed" tabs than to load the corresponding JIRA. Here's an example: https://github.com/apache/calcite/pull/2410 Vladimir
