Define monkeypatching

[jyasskin]

Infra isn't necessarily the right place for this, since final standards don't include monkeypatches, but

1. lots of in-progress specifications include them,
2. someplace should define what that means, for example that "return" inside a monkeypatch returns from the whole surrounding algorithm,
3. we have some best practices that make it easier to maintain and merge monkeypatches, and
4. the people who need this advice are likely to be looking at Infra, but might not find most other places.

I think the section should include guidance like:

• Identify the place you want to modify using both an adjacent step's number and a quote from that step's text, so that when steps are inserted or deleted, it's possible to update the monkeypatch.
• Keep monkeypatches as short as possible. Any more than one or two steps should be pulled out into a separate algorithm that the monkeypatch calls.
• The text of the monkeypatch should be suitable to paste literally into the upstream algorithm, which implies the "return" point above.
• File an issue on the upstream spec to (review and) merge the monkeypatch.

[annevk]

It seems reasonable to have guidance published somewhere, but I don't want it standardized. Monkeypatches are a means to an end and not the one way to do things.

[jyasskin]

w3ctag/design-principles#441 could be the right place to put advisory things.

[jyasskin]

w3ctag/design-principles#441 is merged, so I'm going to close this issue. It might still be useful to say what the wording does, but I can't think of a time that having a better definition in Infra could have prevented an interoperability issue, so it wouldn't be worth spending much time on.