Document criteria for adding a hook
Created by: eileenmcnaughton
We discussed this on PR review & had some rules of thumb
- we only add hooks when input & output is clear
- we don't add hooks in the middle of toxic code
- we don't add hooks to fix in an extension what should be fixed in core (ie - we should do the right fix not the quick fix in all cases)
- we don't add hook into code with known bugs or issues
- in most cases they should have a unit test & the docs PR should be opened at the same time as the main PR (& if not we should probably close the PR until it is 'reviewable'
Some side notes
-
historically we have added a lot of hooks but have wound up supporting some poorly conceived hooks and /or been unable to cleanup toxic code (like in dedupe) due to them being 'jammed in there'
-
as with any feature adding a hook is a transfer of maintenance burden from the submitter to product maintenance.