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 ?
