People aren't lining up waiting to contribute to the project until we accept non-4.0 quality-based contributions. There is a discrete window of opportunity where we as a project can make a first impression on folks interested in joining our community, and signals from people, the data we have available about contributors, as well as basic logic are all consistent that we are turning away new contributors, likely permanently. They're moving on to other projects, since "apparently the Cassandra project isn't interested in new contributions" (interviewees words 2 weeks ago, not mine). Or same sentiment expressed by multiple major companies looking to find a storage coordination layer to put in front of their storage offerings, for instance.
And sorry I can't give you specific names, dates, quotations, and/or contact information Benedict; it seems this rankles you as you continue to use terms like "hypothetical" and "mythical" to describe the very real humans I have spoken with over the course of the past year on this topic. If my constraints of confidentiality from the people I've interacted with are unacceptable for you in a discussion like this and you don't trust me enough to know I wouldn't overtly lie to try and shift an Overton Window, we should probably go ahead and agree to disagree on this conversation and let committers go forward and do what they think best for the project. On Wed, Sep 16, 2020 at 5:09 AM, Benedict Elliott Smith <bened...@apache.org > wrote: > I know. I recognise that is a frustrating aspect of this discussion. It is > something hard to move on. > > So how about we wait until there's a concrete example we can discuss as a > community? If we don't have one, it doesn't seem pressing. > > On 16/09/2020, 08:23, "Mick Semb Wever" <m...@apache.org> wrote: > > Can you provide some concrete examples of your own? > > On a tangent, I really appreciate the work done in the post-mortem > analysis of the 3.0 storage rewrite and just how long that took to find and > fix bugs it caused. The more of that we do the better our QA process will > become and the more we will feel justified/safe in raising concerns about > large patches coming in at the wrong time/place. > > Ironically, this entire proposal so far rests on hypothetical lost > contributions by hypothetical companies and individuals. > > I know. I recognise that is a frustrating aspect of this discussion. It is > something hard to move on. > > I would also like to take issue with a talking point running through much > of this discussion, that those who are focused on quality assurance have > "different priorities" to those who now want to ship features into 5.0: we > also want to ship features, we're just doing the work the project agreed > upon as a prerequisite to that. > > Yes, we have to keep bringing this back to the context that this is an > exception we would be making for specific new contributors we recognise we > would otherwise lose. > > An analogy I see here is how the open source work is done out in the open > but sometimes with new contributors we may make the exception to mentor > them through a patch or two in private to give them a safe space to build > confidence before meeting community rules and precedence. > > I'm hoping that the community transcends the "QA vs New Features" > dichotomy, e.g. with good CI/CD. I think this is now the project's biggest > potential with how the PMC is now spread. That said, AFAIK we are still > waiting on testing/QA requirements/clarifications for 4.0-rc. The best > opportunity we have for QA/CI improvements that will be foundational post > 4.0 is now. > > --------------------------------------------------------------------- To > unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org For additional > commands, e-mail: dev-h...@cassandra.apache.org >
