> 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.
It is an additional cost, but it’s not a high cost. And certainly not a high *marginal* cost - when compared to all the admin involved in getting a patch committed. A tiny extra step. One quick email is nothing. If a conversation comes out of it, then yes, engaging with it will take time, but then again, it’ll also mean that the effort has not been wasted and attracted input. > 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. Many deprecated config params and bits of DDL, for example, would qualify. Some CQL beyond DDL - including early authn/authz bits introduced by me - could’ve been designed better first time around and not need a rewrite/deprecation. > On 6 Dec 2022, at 16:21, Benjamin Lerer <b.le...@gmail.com> wrote: > >> 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 > <mailto: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 >> > <mailto: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 ? >>
