We agreed that it makes sense to clearly identify stakeholders and use cases of the documentation before any action is taken.
This information has been collected in this Google Docs document.
The main stakeholders identified are:
- Site developers: people who create WordPress sites with custom themes and plugins.
- Site builders: people who create sites with primarily a page builder, or a theme that includes a page builder.
- Theme Authors: Developers of WordPress themes, hosted on the official theme directory or elsewhere.
- Plugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party authors: WordPress plugin developers.
- WordPress Core contributors Core contributors are those who have worked on a release of WordPress, by creating the functions or finding and patching bugs. These contributions are done through Trac. https://core.trac.wordpress.org.: People who contribute to the core Core is the set of software required to run WordPress. The Core Development Team builds WordPress. of WordPress, to Gutenberg, etc…
- Content creators: People who create content on WordPress sites.
For each of these stakeholders, the nature of the expectations are different. Theme developers or contributors to WordPress want to be able to alter the way the block 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 works, its structure or presentation; while site builders and content creators expectations will be best met by the user documentation for the block editor.
The major use cases that emerge from all those in the document mentioned above are:
- Update/alter the UI UI is an acronym for User Interface - the layout of the page the user interacts with. Think ‘how are they doing that’ and less about what they are doing. or the structure of the editor and its elements
- Create blocks for the block editor
- Create block patterns
- Programmatically modify or trigger the functioning of the block editor and its elements
The next steps to move forward could be to propose a structure around these major use cases.