Aleksey, I absolutely agree with the point users will be able to give more input, help early on with feedback etc. But I struggle to see why having two sentences explicitly to mention on the ticket the exact API change, which can be even in a new separate required field is not enough to trigger discussion if needed. We can even have mandatory: “Is this API change” and if the answer is “yes” - people should explain in a few sentences
It seems neat to me, streamlined and easy to find historically in tickets. Especially if we consider many of them will be accepted with lazy consensus as it was pointed out earlier on this thread. On Tue, 6 Dec 2022 at 10:18, Aleksey Yeshchenko <alek...@apple.com> wrote: > Public APIs are 1) essentially forever-lasting and 2) are what our users > actually get to interact with. A suboptimal public API can be annoying to > work with at best, and at worst force and cement suboptimal implementations. > > The goal here is to make sure that whatever public API changes we > introduce are as good as they can be, first time around. Getting as many > diverse eyes on it as possible helps with achieving this goal. Making these > changes more visible and allowing for longer periods of revision maximises > the opportunity for someone to spot an issue or suggest an improvement. > > This isn’t about trust, but about recognition of one’s own limitations. > Most active committers - *absolute* most of us - are indeed *not* Cassandra > users or Cassandra operators. Our predominant interaction with Cassandra is > via editing Java code in our IDEs. We don’t usually have a lot of > experience or skin in the game when it comes to consuming Cassandra’s APIs. > We should welcome and actively seek inputs of those who do. Giving more > time to other developers to react and contribute is pretty important as > well. > > The mechanisms suggested here don’t strike me as being too costly. > Starting a lightweight informal thread even for every individual proposal > is no huge deal, surely. We aren’t talking about CEP level of commitment > here. > > It’s not the first time you bring up trust, I feel, but there really is no > need to go all defensive here. No person or organisation is being singled > out. Admitting that API design can genuinely benefit from user input and > input of others in general, to me, is productive humility - a sign of > maturity. It’s not a reason to be offended. > > > On 6 Dec 2022, at 13:53, Benjamin Lerer <b.le...@gmail.com> wrote: > > > > I am sorry but I still do not understand what problem we are trying to > solve. > > All examples given so far have been about significant features which we > already discuss on this mailing not about minor changes that happen > multiple times per week. > > Is it a trust issue ? > >
