What is the Next Level of detail?

[joshkoenig]

Right now, this content is relatively high level. It should serve to orient developers and site owners around how to think about the challenges of scaling — which is much needed. However it is the vision of this project to offer a (if not the) canonical resource for technical information about scaling WordPress, and this is where we hope to see more contributions going forward.

In the short term, what's not obvious in the github repo is that the website will include multiple resource links for each section that can highlight existing resource that are already out there delving into the specifics. Not sure yet how we can have a community discussion about that, but maybe we'll materialize those resources — which are just a title, a sentence, and a link, with a category attached — into markdown files as well.

But more durably, I'd love to have a discussion about identifying and pursuing the "next level" of content that makes sense here. This was @tollmanz's first comment, and @westonruter 's input around Fragments (issue #8) is a good example of how naturally this conversation comes up though.

There are three challenges as I see it:

1. Coming up with a coherent target for what the next level is — e.g. how into the weeds should we get? I'd like to keep it consistent, so targeting a relatively even level of detail to target seems important. Likewise we should figure out where to draw the line in terms of things that can help all/most/many sites, vs things that are really important, but only in certain specific circumstances.
2. Avoiding stuff that's unhelpfully debatable. One of the benefits of keeping it high level is that we don't need to caveat things or offer too many duplicative choices. E.g. I don't feel like it's helpful to try and have a "Apache vs Nginx" section, or to try and pick a winner between effectively equivalent technologies. These debates are generally anti-patterns in my opinion.
3. Properly recognizing prior art. The more detailed this gets, the more I feel like we might be stealing the thunder of existing resources. If all goes super well, we can bring experts in as part of the process. That's also why the initial plan is to lean on external resources for "next step" stuff. However, maintaining more "canonical" documentation over time would be great.

But I'd very much like to hear from other folks. What would you like to see? Should we dive right in to listing example config files? Should we work on calling out edge-cases and gotchas? What would help you and your teams, and maybe more importantly, what do you think would help educate the next generation of scalability architects and engineers?

[westonruter]

Targeting a high-level overview with links off to existing deep-dives on the Web seems like a good way to go, since there is a lot of prior art, although it doesn't seem to be all collated together (hence the purpose of this project). If there are any specifics that are lacking prior art, then new blog posts could be written and linked to for more details instead of trying to fit everything into the content here.