/tg/Station 13

The feature freeze has been going well but a few things that are between what are technically features and fixes have occured.

Should we change the name to rework features (Meaning anything but new big changes)?

That is pretty much what I am asking because as it seems some people would be fine making fixes but they seem to do it in a way to get features in by loopholes.

Either way, what should happen is that a far more definitive, and agreed upon, definitions of what exactly can and cannot be done be written up. That, ontop of renaming any future Feature Freeze's to Feature Reworks would be a good idea in my opinion.

What we had were a lot of PR's that did not easily fall into the only two exceptions to the freeze (sprite and minor map changes) that were granted exceptions on the whim of whoever was on it at the time and the argumentation skills of the person doing the PR.

I haven't been coding much lately, but from a player's perspective, it seems to me that this feature freeze has held back a lot of great things while letting game-breaking bugs through. We seemed to do better before the freezes, which I vaguely suspect is because testing for new commits has gotten less rigorous.

I hate Feature Freezes with a passion. It's like cutting individual strands of hair, it is painfully inefficient.
If you want to be more efficient with stomping bugs, aggregate them based on systems. If a coder takes on a project relevant to that system he is going to know how the code works better,have more extensive testing of the whole system and be more motivated rather then having a pointless no features restriction on his head.

Bugs that are high priority are going to be fixed anyway feature freeze or no feature freeze.
If a coder makes a feature that introduces bugs he can be restricted until he fixes it, there is no point in penalizing other coders for features they haven't made.
Sure sometimes coders drop of the face of the earth and others have to step up, but you don't need a month of feature freeze for it. If coders were roughly responsible for systems they are familiar with things would go more smoothly.
For example in the case of Atmos we all know Aran is the master. If another coder were to work on an atmos feature(if Aran doesn't silently assassinates him) the one who would fix any bugs from that would be either the one who made the feature or Aran regardless of the feature freeze.

adrix89 wrote:I hate Feature Freezes with a passion. It's like cutting individual strands of hair, it is painfully inefficient.
If you want to be more efficient with stomping bugs, aggregate them based on systems. If a coder takes on a project relevant to that system he is going to know how the code works better,have more extensive testing of the whole system and be more motivated rather then having a pointless no features restriction on his head.

Bugs that are high priority are going to be fixed anyway feature freeze or no feature freeze.
If a coder makes a feature that introduces bugs he can be restricted until he fixes it, there is no point in penalizing other coders for features they haven't made.
Sure sometimes coders drop of the face of the earth and others have to step up, but you don't need a month of feature freeze for it. If coders were roughly responsible for systems they are familiar with things would go more smoothly.
For example in the case of Atmos we all know Aran is the master. If another coder were to work on an atmos feature(if Aran doesn't silently assassinates him) the one who would fix any bugs from that would be either the one who made the feature or Aran regardless of the feature freeze.

There are some good ideas here on how to go forward, but before we reach that point, previous messes need to be cleaned up. I should add we still have some horreoundus monstrosities of implementations from googlecode era that cause long, long term headaches as refactoring and redesigns are required.

I think this mostly boils down to much more rigorous and in-depth testing to stop the issues list getting out of control, but in a game so varied and wide as SS13, this can sometimes prove difficult, particularly with features that are widely used such as mob based code.

I have some professional software testing experience, and I could easily envision things like test plans and test phases planned out, but I think having that expectation would put a lot of people off working on the project under the criticism of a lot of beaurocracy. You know how nightmarish we all hear about how game testing is? Because it won't be too far from that.
We could also have contributors demonstrate they are able to test their code as widely as possible... if code gets through and is shown to be terribly buggy, more pressure will be put on them to show better testing when they open new PRs in the future. Regardless on where a contributor is on a spectrum of doing good or bad testing, this will slow development and changes to the game. That is good for the quality of the project, but no one is going to have the right to complain about little being done by coders.

Sprite edits and map changes are excluded from the freeze. This has always been the case since I've been headcoder (due to my pre-headcoder experience with freezes, where I was still exclusively a spriter). While coders are expected to work on coding bugfixes... spriters and mappers cannot. It's not our intention to have these people sitting around doing nothing for a month. That's frustrating and unproductive.
I think there was some confusion there? Some people expected that new sprites or map chances couldn't be added.

You can see this right in the freeze thread, https://tgstation13.org/phpBB/viewtopic.php?f=5&t=273 under Exceptions.


Adrix, feature freezes aren't meant as a "penalty". I guess fixing things is seen as less satisfying that making new Ian hats or whatever? Personally I enjoy shredding bad code; seeing the line added/removed comparison between it and my new elegant solution. We have two guys who fix bugs exclusively.

adrix89 wrote:I hate Feature Freezes with a passion. It's like cutting individual strands of hair, it is painfully inefficient.
If you want to be more efficient with stomping bugs, aggregate them based on systems. If a coder takes on a project relevant to that system he is going to know how the code works better,have more extensive testing of the whole system and be more motivated rather then having a pointless no features restriction on his head.

Bugs that are high priority are going to be fixed anyway feature freeze or no feature freeze.
If a coder makes a feature that introduces bugs he can be restricted until he fixes it, there is no point in penalizing other coders for features they haven't made.
Sure sometimes coders drop of the face of the earth and others have to step up, but you don't need a month of feature freeze for it. If coders were roughly responsible for systems they are familiar with things would go more smoothly.
For example in the case of Atmos we all know Aran is the master. If another coder were to work on an atmos feature(if Aran doesn't silently assassinates him) the one who would fix any bugs from that would be either the one who made the feature or Aran regardless of the feature freeze.

People enjoy fixing bugs. It's also a good opportunity to focus on rewriting bad code so features can be implemented easily in the future.

Scott wrote: Some people enjoy fixing bugs. It's also a good opportunity to focus on rewriting bad code that will not be merged because it causes gameplay changes and thus is a 'feature'.

Fixed that for you.

If something has a significant impact upon how the game is played, then yeah it should probably wait. If fixing the bug has a very minor effect then it's probably fine? If you have any concerns as to whether something you are or are planning on working on will be counted as a bug or feature, all you have to do is ask in IRC or send a PM to either myself or another head/maintainer.

Cheridan wrote:If something has a significant impact upon how the game is played, then yeah it should probably wait. If fixing the bug has a very minor effect then it's probably fine? If you have any concerns as to whether something you are or are planning on working on will be counted as a bug or feature, all you have to do is ask in IRC or send a PM to either myself or another head/maintainer.

The point I am making is that rewriting code has nothing to do with the feature freeze, since usually reworking something does make gameplay changes.
It is simply not an incentive.

even if it's not an incentive to rework large things, it's an incentive to fix the hundreds of small bugs we have

adrix89 wrote:

Cheridan wrote:If something has a significant impact upon how the game is played, then yeah it should probably wait. If fixing the bug has a very minor effect then it's probably fine? If you have any concerns as to whether something you are or are planning on working on will be counted as a bug or feature, all you have to do is ask in IRC or send a PM to either myself or another head/maintainer.

The point I am making is that rewriting code has nothing to do with the feature freeze, since usually reworking something does make gameplay changes.
It is simply not an incentive.

And the point I'm making is that if a significant code fix would have a minor gameplay impact then it's probably permissible even while in freeze. Sometimes there's overlap between fixing an issue and making a feature. Case in point, https://github.com/tgstation/-tg-station/pull/5936 Does it have a gameplay change? Yeah, but it fixes an open issue and the code change is light enough to permit. Again, if you have doubts about something being allowed then all you have to do is ask.

Cheridan wrote:And the point I'm making is that if a significant code fix would have a minor gameplay impact then it's probably permissible even while in freeze. Sometimes there's overlap between fixing an issue and making a feature. Case in point, https://github.com/tgstation/-tg-station/pull/5936 Does it have a gameplay change? Yeah, but it fixes an open issue and the code change is light enough to permit. Again, if you have doubts about something being allowed then all you have to do is ask.

That is not the argument I am making. Scott was saying a feature freeze is an incentive rework bad code. That is not the case since most of the time reworking code usually causes major changes to gameplay.
It simply does not work as an incentive.

Sure it is possible to rework code and not have to much impact so that it does go thought the feature freeze. But the other way around is also possible.
The feature freeze does fix bugs, but I don't think its efficient way to do things.

I clearly said it's a good opportunity to do it, not that it is an incentive to do it.