> > It’s not the first time you bring up trust, I feel, but there really is no > need to go all defensive here.
I am not defensive. I am simply trying to understand the need to put in place a process that has a high cost in terms of time and effort for small changes. So far nobody has been able to provide me with examples of times where it would have been needed. I am sorry. I see the cost not the benefit. Le mar. 6 déc. 2022 à 16:18, Aleksey Yeshchenko <alek...@apple.com> a écrit : > 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 ? > >
