@@ -64,3 +64,16 @@ With the plan to add new columns, the only relevant impact here should be that a
1. Data Processor
1. SearchKit
1. Afform
## Manageability
There were some difficulties it would be nice to avoid in future, related to the PR being such a big PR:
1. (Real problems, that happened)
* Rebasing such a PR when there's a conflict is painful and costs money and requires retesting and re-reviewing, even when it has smaller commits within a PR.
* Stuff can go missing.
* There's an incentive with big PRs to "get this merged before it goes stale", which is not an ideal.
2. (Theoretical, but has happened elsewhere.) Possibly another PR that gets merged requires a change to the code, but it gets rebased verbatim, and doesn't get retested and then fails later.
3. (Theoretical/Opinion) It is offputting and difficult to do code review for such PRs. Perhaps fewer people than normal looked at the code.
It was mentioned at one point in the review to break it up, but it seemed difficult to do at the time. Perhaps if being refactored it can be planned in a way this can be achieved.
