Feature Freeze Proposal

Halflife_3_Confirmed is proposing feature freeze to be immediately enacted following Checkpoint 1, until codesmells are below 100, and test coverage exceeds 60%.

The feature freeze would prohibit the creation of any code that enables new functionality, on any branch (local or remote). Only code that serves to assist refactoring, fix bugs or simplify interfaces will be permitted. Tests can still be written.

Rationale

Technical debt and feature creep have started to make the codebase substantially more difficult to navigate and work with. Pyramid Scheme has quite a high Codesmell-to-LOC ratio compared to other groups, and the second lowest test coverage at the time of writing.

A unified effort by the entire team to fix these issues will pay dividends down the line.

Why does the entire team have to buy into this?

Currently, groups are trying to churn out features and merge then so that the resolution of merge conflicts is the responsibility of groups that merge later.

Thus, rational groups, so as not to accrue merge conflicts that they have to resolve, do not write tests, do not write documentation, and do not refactor, preferring to do these after the feature has been merged. (NB: I am guilty of this myself).

A feature freeze allows all groups to improve the health of the codebase without worrying that they are "falling behind".

However, the effectiveness of the freeze breaks down if groups choose to violate it. If another group chooses to write code that contributes to new features, it is no longer rational for groups to continue refactoring, and more groups are likely to violate the freeze.

It will be up to all groups to ensure that the freeze is being adhered to. The feature freeze will only be enacted if 100% of groups pledge to adhere to it.