Let's talk about Feature Freezes

[ohnopigeons]

Imagine if you will the concept of technical debt. Typically this term is used for band-aid/hack solutions but it also applies to feature additions as well. Part of the reason why "feature creep/bloat" is derided as such because they increase complexity and lines of code, and therefore problems. We don't have a very strict testing regime other than a compile check (nor is one possible, I think) so combined with a large number of disjoint feature PRs, inevitably and statistically these will cause issues and bugs even with maintainer review/approval. A feature freeze is equivalent to a period of technical "austerity", if you will, where the goal is to pay off and reduce debt, which what one generally should do with debt but it also serves to prevent runaway technical debt where the project becomes an unmaintainable mess, a real possibility for this codebase.

You will notice, as some have pointed out, that the issue count after the most recent freeze is higher than before the freeze. The is par the course, as technical debt before the freeze was catching up, manifesting itself as issues at a faster rate than the rate of fixes. Of course not all issues are technical bugs nor should the issue count be used as a concrete metric.

As such, the following should continue to be disallowed in feature freezes, as they increase technical debt:

• Features
  Tweaks
  Map Edits (that are not fixes)

However, the following (that were restricted) should be allowed in future feature freezes:

• Refactors
  Removals

Refactors are a subset of code improvements. It's true that refactors may cause some issues in the short-term, but they improve maintainability and prevent more issues in the long-term. Refactors are a good thing and should always be encouraged. Refactors that don't improve code should not be merged regardless of whether or not there is a freeze.

Removals are the opposite of feature additions. I realize that removals are generally controversial, but they reduce lines of code and complexity and are therefore a good thing technically. Assuming the existence of valid removal PRs that would be merged outside of a feature freeze, they should also be allowed during a freeze as well.

Balance PRs are tricky.
Over the course of a feature freeze gameplay changes induced by fixes and/or shifts in player behavior can cause signficant balance issues that need to be addressed. As such, I don't like the idea of balance changes being completely denied especially for a signficiant period of time. However, a blanket allowance of balance changes can be abused. I'd recommend only allowing balance PRs only with prior headcoder/design-lead/headmin/whatever approval.

In Summary:
Completely allow refactors and removals during feature freezes, as they help fulfill the ultimate purpose of feature freezes. Allow balance changes only with prior approval for freeze sustainability.

[Jalleo]

The problem is that these refactors of recent have been too large and therefore been bugged. Also this isnt a economy its a punch of random people all throwing paint everywhere with it sometimes being called art or good.

[Dax Dupont]

A lot of the relatively recent PRs have been caused by the following refactors:
Storage caused like 20
Attack hand refactors we're bad too
Killing off item/devices wasn't in for 10 hours and already caused two fix PRs
Shuttle refactor caused like 15 issues.

Refactors on tg tend to make things way worse. The ticket count kept rising because of the after affects of refactors staying on for months.

Also the issue tracker has a lot of old open issues that no longer exist and someone needs to go through and try to replicate the issues.

[ohnopigeons]

The problem is that these refactors of recent have been too large and therefore been bugged. Also this isnt a economy its a punch of random people all throwing paint everywhere with it sometimes being called art or good.

Refactors come in all sizes and I suspect the smaller refactors are being passed off as "Code Improvements". Some short-term bugs should be tolerated for the long-term gains. If a refactor is completely nonfunctional and breaks everything then it's a bad refactor and the fault of the author.

An economy is also a bunch of random people doing doing random and different things, no? Just taken at a large-scale to be more predictable and manageable. It's why feature freezes exist in the project in the first place and why they work as much as they do.

A lot of the relatively recent PRs have been caused by the following refactors:
Storage caused like 20
Attack hand refactors we're bad too
Killing off item/devices wasn't in for 10 hours and already caused two fix PRs
Shuttle refactor caused like 15 issues.

Refactors on tg tend to make things way worse. The ticket count kept rising because of the after affects of refactors staying on for months.

Also the issue tracker has a lot of old open issues that no longer exist and someone needs to go through and try to replicate the issues.

You're focusing too much on the issue count as a concrete metric and not thinking in the long-term. For a project that has "random people all throwing paint everywhere" refactors become all the more important. Some of the systems you've described are inherently difficult, refactor or not, and would cause issues down the line without such refactors, if not more. Some refactors seem like blanket refactors that did not have much thought put into them; these are bad refactors. It doesn't mean you give up on refactors.

[The Clowns Pocket]

Yeah! I mean, who really wants to add features? Removing features is where it's at!

[onleavedontatme]

The reason we bar balance changes and removals are for maintainer sanity. We need breaks from the year round bikeshedding, and time to focus on fixes.

I agree refactors are important, it was why we were allowing them with prior approval.

[ohnopigeons]

I agree that there is a substitutive relationship between bikeshedding and productive work, but it is not zero sum. We are a FOSS project being run by volunteers not salaried/on-the-clock employees with a financial stake on the overall product; time spent on bikeshedding does not automatically translate to time being spent on fixes if you ban bikeshedding. Removals however always produce intense, unrivaled levels of bikeshedding so I'll relent on that.

Balance PRs (with prior approval from, you, basically if not headmins) are meant for player sanity so that freezes can more smoothly last the month, if not longer. I still think these should be a part of a feature freeze even with the bikeshedding involved. You're never going to eliminate bikeshedding anyways as fixes produce a fair amount themselves.

I also still don't think prior approval is necessary for refactors, since bad refactors shouldn't be merged outside of a freeze either and the approval serves no apparent purpose from what I can see. Maintainers have different levels of expertise in different areas so I don't know how gating discussion and review over refactors is productive.