Marcos Cáceres

Can you help me understand a bit more of what we want to achieve here? The original plugin design was to allow anything synchronous (e.g., preloading, loading styles, etc) in...

I'm not really liking the `conf.state` thing... could each plugin just export its own state instead?

> As we've access to conf and state, we can start some requests earlier in parallel without waiting on other plugins. So we should get faster processing instead of "slow...

> Someone on yesterday's call mentioned that ReSpec had a classname to mark a feature as a potential fingerprinting risk, This was actually something in HTML, but BikeShed now supports...

Ok, this approach is interesting and not at all what I was expecting: that is, I was not expecting a box describing the rationale for the changes. Rather, I was...

Just to straw-person this out: * If there is a deletion, them just delete (will show up in htmldiff and in changelog). * If it's a "correction", add `` and...

(about "candidate" VS "proposed" ... yeah, that's confusing... I'll have a read... but that sounds like there should only be one)

I think this is still risky... I'd prefer people just user preProcess and postProcess. Hooking into anything makes things fragile, as we've seen.

> As an example, if you look at respec.org/docs/src.html#L29-L36 (and respec.org/docs/src.html#L98-L128 in particular), you'll see what hacks I had to make to overcome the limitations of preProcess and postProcess 😅...

I still think this is going to be extremely footgunny. > Currently linters run after doc.respec.ready, which means we can miss linter warnings in respec2html (to workaround this, we wait...