Hi Dev, What principles do we have? How do we implement them?
Our team has been evaluating 3.0.x and 3.x for a large production deployment. We have noticed broken tests and have been working on several patches. However, large parts of the code base are wildly untested, which makes new contributions more delicate. All of this ultimately reduces our confidence in the new releases and slows down our adoption of the 3.0 / 3.x and future 4.0 releases. So, I'd like to have a constructive discussion around 2 questions: 1. What principles should the community have in place about code quality and ensuring its long term productivity? 2. What are good implementationg (as in rules) of these principles? To get this started, here is an initial proposal: Principles: 1. Tests always pass. This is the starting point. If we don't care about test failures, then we should stop writing tests. A recurring failing test carries no signal and is better deleted. 2. The code is tested. Assuming we can align on these principles, here is a proposal for their implementation. Rules: 1. Each new release passes all tests (no flakinesss). 2. If a patch has a failing test (test touching the same code path), the code or test should be fixed prior to being accepted. 3. Bugs fixes should have one test that fails prior to the fix and passes after fix. 4. New code should have at least 90% test coverage. Looking forward to reading your feedback, @fdeliege
