Hi Navis, we definitely understand the concern. I think the best way to avoid this problem is to submit proposals similar to https://github.com/druid-io/druid/issues/3378 before code has been written to let the community know what is being worked on so everyone can coordinate. If there are disagreements with the proposal, or alternative architectures to consider, we highly encourage bringing them up in the proposal so that we can openly discuss issues. Overall, we strive to follow the ASF model of reviewing proposals and PRs.
For example, see https://github.com/druid-io/druid/issues/3147. There was a full discussion on the scope of changes being made, and the final PR https://github.com/druid-io/druid/pull/3148 incorporated the feedback that was given from the proposal.
We are working on a plan to best determine how to merge all of your PRs into trunk. I think the most important thing for us is to understand which proposals are high priority and critical for you guys, and which proposals are less critical. It also helps us a lot to know which PRs have been validated in production, and which ones have not.
For https://github.com/druid-io/druid/issues/3378, it would be great to understand, from an architecture and implementation perspective, your concerns on the direction and proposed implementation. I think as Druid committers we should strive to make the best architecture decisions possible and ensure the project follows a good direction. For your particular set of changes related to #3378, we can also discuss the best way that we can incorporate both sets of work so you can continue to use your contribution in that proposal.
I understand that this process is a bit frustrating. The main problem is that there is an extremely small number of committers that actually review code as everyone else wants to build features instead. I hope that as committers, we can divide time equally between code review and feature development.
Does this sound reasonable?