Code Stability Working Group
Scope and Objectives
In community discussions via email, over Slack and on our weekly technical calls, it has been determined that we would be better-served with a set of practices that provide a smoother process for developing and releasing new features while maintaining stability and backwards compatibility. Therefore, we propose a working group to define efficient processes for maintaining a stable, evolving code base. This group should achieve its mandate within 30 days.
These processes should ensure that:
We merge new features into the existing code base without disrupting it
We develop new features in small increments that enhance without disrupting the code base, in order to maximize productive additions
We have the means to educate our community with the knowledge needed to evaluate pull requests to ensure they do these things
We have a baseline set of standards we agree on that provide the basic requirements for meeting these requirements
These standards are publicly available and the larger community is well-informed about them. An example standard might be:
- tests that prove regression behaviors are unharmed and new features deliver their intended benefit
We have defined a set of practices that guide stable development strategy, for example:
- The first PR to a new feature is flip-flop toggle
- Code gets merged when it provides some quantitative benefit without causing bugs or interfering with other features
- A test suite that serves as the benchmark for backward compatibility, if feasible
We explore the possibility of backward-compatible data-migrations, their feasibility and defining characteristics
Deliverables
- A set of standards and practices that promote code stability and backwards compatibility, throughout feature development, testing and releases
The larger community is fully informed of them, both upon their completion and on ongoing basis (through public documentation)