Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

Version 1 Next »

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)
  • No labels