In short: The number, definition, and overall usage of phases deserves a review. It was made just as a guess of what will be needed, and we can apply our current experience. We could also wait for some rules writing UX.

(17:17:00) ozizka-FN: jsightler: What's the plan with phases?
(17:17:12) ozizka-FN: To be removed?
(17:17:20) jsightler: yeah, we have talked about that.
(17:17:32) jsightler: We haven't fully designed out the replacement, though.
(17:19:39) ozizka-FN: What's the motivation for removal? Makes things complex in code or for user or both?
(17:20:53) jsightler: ozizka: Well, that's part of my issue, tbh – I don't really understand the case for fully removing them.
(17:21:15) jsightler: One significant issue is that they are currently too inflexible. (It's impossible to add custom phases, eg)
(17:22:42) jsightler: ozizka: Idk – what do you think?
(17:24:45) ozizka-FN: jsightler: I see them as shortcut of before/after -
(17:24:54) ozizka-FN: kind of bariers (in programming sense)
(17:25:09) ozizka-FN: maybe we could reduce the number,
(17:25:19) ozizka-FN: at least to have the "core rules" phase
(17:25:25) ozizka-FN: like unzip, scanning, ...
(17:25:37) ozizka-FN: and then let the sorter sort the rules
(17:25:50) ozizka-FN: and then reporting
(17:26:10) jsightler: ozizka: That's a good point, although reducing the number might make the before/after becomes more complex in the "core" rules.
(17:26:43) jsightler: It's probably worth building a report on all rules/phases to see which ones we are actually using, and how we could refactor to simplify them.
(17:27:52) jsightler: (the phases that are there now were basically just a guess at what maybe would make sense... they could probably be completely redone now to be a lot better)