> 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.
