As you may know, the “Full Site Editing via Gutenberg” is the main goal for 2021. We still don’t know when exactly it will become the part of core but to avoid missed opportunities (as we had them in the past with Gutenberg) let’s start preparing documentation space for this new feature’s arrival.
We want to join efforts with other teams already working on Site Editor. Namely, the Test team has an ongoing Outreach Program (lead by @annezazu), Themes team (mostly @poena) is explaining what this feature is and how it’s working, Core and Design teams are building it: pull requests and issues.
Our job is to document it.
First things first
Before we start with anything else, we need to know two things: the name and the place.
The name
It’s been called “Full Site Editing” throughout the community but, as history teaches us, this is most likely to stay around only as the code name for the project, used among people working on it.
We will probably have a different name facing documentation consumers so, to avoid confusions and to have a proper Handbook slug from the beginning, we might want to spend some time on thinking it through. This is not a task only for the Documentation team, of course, and we hope to get input on this post from all teams involved.
It’s been suggested in #docs chat, that “Site Editor” might be an appropriate name (just as Gutenberg became Block Editor) so we’ll use it as a starting point. Please leave your opinions and suggestions in the comments below.
The home
The whole user facing documentation is roughly divided into end user documentation (HelpHub) and developer documentation (DevHub). Obviously, Full Site Editing feature should be explained to both, in a way that is useful to each group.
@bph is already doing an amazing job in organising and creating content for end user Block Editor documentation and she has a plan for Full Site Editing feature.
The problem we are facing is the home for developer part of Full Site Editing feature documentation. It doesn’t fully belong to any existing Handbook as it requires features from different areas (it needs to be enabled in theme but it assumes template post types, it doesn’t create new blocks but it does use blocks specifically created for it, it can use global styles etc).
Majority of the Documentation team agrees that Full Site Editing feature shouldn’t be buried in any one existing Handbook but it should be mentioned where relevant. Also, we agree that the full concept should be explained in one place from and to where we can easily inner link relevant places in other Handbooks.
Considering there might be much more to Full Site Editing feature in the future and we might need more space for it than, say, one page, the Documentation team propose a new Handbook under DevHub.
The slug for this Handbook depends on the name we settle with. Also, it would be a good time to decide if we want to have this Handbook built and generated from GitHub (like WP-CLI, REST API, Block Editor and Coding Standards are) or do we want to publish content directly from WordPress.
Please leave your feedback in comments below by 25th February. Thank you.