Add guidance for monkey patching

[marcoscaceres]

Closes #184

---

Preview | Diff

[kenchris]

This LGTM!

[atanassov]

Suggested change

	An example of monkey patching would be: specification A defines an algorithm to do something, then specification B overrides or modifies that algorithm with some new functionality.
	An example of monkey patching would be: specification A defines an internal algorithm part of its capability, then specification B overrides or modifies said algorithm with functionality directly, not using publicly defined extension points.

[atanassov]

The abstract example is a bit confusing to the reader as it almost implies that no spec should extend another spec. My proposed change could be a good start to make the text a bit explicit. Ideally, we will have examples from the past to illustrate what a monkey patch is and why it is bad. We should also clarify the difference between monkey patching (bad) and modularization (good). Maybe also link to https://en.wikipedia.org/wiki/Monkey_patch

[annevk]

This looks great. My main suggestion is to use the same words throughout for things so it's crystal clear they're about the same thing.

[marcoscaceres]

@atanassov wrote:

The abstract example is a bit confusing to the reader as it almost implies that no spec should extend another spec.

I'll linked to the guidance.

Ideally, we will have examples from the past to illustrate what a monkey patch is and why it is bad.

I'd like to not call out any one spec, but even the example that was originally there is now broken for exactly the reasons we mention in this section:
https://wicg.github.io/web-share-target/#extension-to-the-web-app-manifest

The Web Manifest spec doesn't no longer uses WebIDL, just for starters 🤦‍♀️

We should also clarify the difference between monkey patching (bad) and modularization (good).

I added some preliminary text.

Maybe also link to https://en.wikipedia.org/wiki/Monkey_patch

Linked..

[LeaVerou]

LGTM and @plinss with the changes