Plan proposal for a new better structured Gutenberg developer documentation

I’ve recently volunteered to be the GutenbergGutenberg The Gutenberg project is the new Editor Interface for WordPress. The editor improves the process and experience of creating new content, making writing rich content much simpler. It uses ‘blocks’ to add richness rather than shortcodes, custom HTML etc. developer documentation team repTeam Rep A Team Rep is a person who represents the Make WordPress team to the rest of the project, make sure issues are raised and addressed as needed, and coordinates cross-team efforts..

This is a proposal of next steps for a friendly Gutenberg developer documentation, useful for newcomers.
For more context about the current state about Gutenberg dev docs, and its challenges, read this:

The plan is to build on the existing documentation ( to arrive at a better structured doc.

Here are some aspects that I thought the team could focus its discussions and reflections to get started.

Where are we at now?

It is essential to have an overview of existing documentation. Both the one present on, on GitHub (if there is any), and also those in progress. This is to avoid dispersing our efforts, and to take advantage of the work already done by other contributors and volunteers.

What should be included?

In my view, one of the first step would be to agree on what should be included in the new documentation. There are currently many concepts (CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. concepts, APIs, etc…) that can be useful for developers using the blockBlock Block is the abstract term used to describe units of markup that, composed together, form the content or layout of a webpage using the WordPress editor. The idea combines concepts of what in the past may have achieved with shortcodes, custom HTML, and embed discovery into a single consistent API and user experience. editor. Some of them are already present in the current documentation. Others are in the codebase on the project’s GitHubGitHub GitHub is a website that offers online implementation of git repositories that can easily be shared, copied and modified by other developers. Public repositories are free to host, private repositories require a paid subscription. GitHub introduced the concept of the ‘pull request’ where code changes done in branches by contributors can be reviewed and discussed before being merged be the repository owner. repository.

A new structure?

The current structure of Gutenberg’s developer documentation is one of the aspects that makes it not friendly at all. For example, the home page of the documentation starts with the chapter “Creating Blocks”. A beginner is like thrown into the cauldron without knowing the prerequisites. Several contributors also address the question on GitHub here

In this regard, I think we could learn from examples of documentation such as Gatsby.js (a quick start/tutorial, then a reference guide that discusses key concepts in a more or less defined order).

Cross-team collaboration

How do we want to collaborate with the different teams to make this happen? From here I see the core-editor team playing an important role, given their experience with the block editor development.

What’s next?

At this stage, we are only at the discussion stage, to see what is feasible and the best way to do it. If you are interested in helping with any of the steps, please feel free to comment. Also, if you have other points that you think are essential or need to be discussed in this plan, please feel free to mention them in your comments.

Season of Docs 2020

With the Season of Docs starting in a few weeks, I think this could be a great opportunity to move forward on that plan.

There are two projects in particular that could help:

  • Project #6 with @kenshino: Improve Existing Development Documentation and Handbooks and
  • Project #8 with @milana_cap: Extending Block Editor.

#block-editor, #documentation