Discuss the ideal granularity for explainers

[jyasskin]

How "big" should an explainer be? We've had problems when teams send us lots of explainers for tiny incremental features, but we'd also have trouble reviewing diffs against a single explainer that covered their whole space. I think we probably want explainers to cover the proposed change from the model of the Web that's in the reviewers' heads. Of course that's ambiguous because there are many reviewers with different amounts of context, but maybe we can use the "newly available" Baseline. Something like:

Your explainer should explain the difference between the "newly available" Baseline and the Web that solves the problem you've chosen. It can make sense to divide that delta among several explainers, but make sure those explainers each cover a logical feature set and that you don't make readers click through "too many" different documents (<=5?).

[LeaVerou]

I think it's not about size, it's about structure. Ideally, a good explainer is hierarchical, starting from a tiny tl;dr and providing pointers to dig in more if something is unclear.

Both of these are problematic:

• a huge explainer that cannot possibly be processed in the available time, so it's haphazardly skimmed
• a tiny explainer that lacks essential info