Editor chat summary: 15 January 2020

This post summarizes the latest weekly Editor meeting, held in the #core-editor Slack channel, on Wednesday, January 15, 2020, 14:00 UTC. These meetings coordinate collaboration in the development evolution of 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. https://wordpress.org/gutenberg/ project. Facilitator: @pbrocks Notetaker: @itsjusteileen.

Weekly Priorities

We’re working on a few post-related blocks to use for FSE templates (starting very basic) and improvements to 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. UIUI User interface is being iterated on here PR 19344. The navigation  block is also very important as we get closer to WordPress 5.4:

  • Block Content Areas (Full site editing)
  • Block UI updates
  • Block Patterns
  • Navigation block improvements

Task Coordination

@andraganescu:

  • Adding niceties to the media replace control and tidy up issues for the navigation block

@youknowriad:

  • I’ve been working a little bit on the LinkControl component (code cleaning essentially) and trying to use it in more than just the Navigation block.
  • I’ve helped a little bit on what we call G2 (new Block UI)
  • I’m also doing a push on triagetriage The act of evaluating and sorting bug reports, in order to decide priority, severity, and other factors. as the issues and PRs are getting out of control 
  • Reviewing some FSE PRs

@scruffian:

@gziolo:

  • Polishing npm init wordpress-block script, and plans to open PR against Gutenberg next week (demo in the thread)
  • Continued explorations on how Patterns APIAPI An API or Application Programming Interface is a software intermediary that allows programs to interact with each other and share data in limited, clearly defined ways. could be integrated in the inserte 

@karmatosed:

  • Navigation: reviews, iterations.
  • Global styles: mocks and flows, trying to sync work there.
  • A continuous undercurrent of triage.

@retrofox:

  • Background Color for the <Navigation /> block. Pretty close to get a first solid approach.

@jeryj:

  • Various small improvements to the navigation block and color picker component.

@mapk:

  • Moving some links around to minimize the repetition of “Tools” areas in the interface: 
  • PR 19499
  • PR 19400
  • Looking at Template and Template Part UXUX User experience flows.
  • Posts block design ideas.

@getdave working on: 

  • Focusing on how to improve LinkControl both within Navigation Block and also when in use in wider Editor. Lots of movement here by others also to make this component more useful.

@michaelarestad working on:

  • List of Epics for Full Site Editing
  • Flows
  • Iterating on mocks to reflect recent changes

@mcsf working on:

  • Exploring how we can take block patterns, as @gziolo is working on, to simplify / converge how we implement Embeds and hopefully Social Icons

@isabel_brison working on:

  • Brought Resizable Editor work to a reviewable state: PR 19082 (tests are still failing, but feedback on implementation appreciated)

Open Floor

Changelog Entry Standard

@nadir is looking for a way for PR others and maintainers to write a standardized PR changelog entry that can be aggregated by a script that generates the changelog. Initial idea discussion in Slack

@youknowriad provided steps he used for Gutenberg release:

  • Go through the list of all PRs merged for that release and milestone them properly
  • Copy the title of these PRs and add a link to the PR as a changelog entry
  • Choose the right section (bugbug A bug is an error or unexpected result. Performance improvements, code optimization, and are considered enhancements, not defects. After feature freeze, only bugs are dealt with, with regressions (adverse changes from the previous version) being the highest priority., enhancementenhancement Enhancements are simple improvements to WordPress, such as the addition of a hook, a new feature, or an improvement to an existing feature., new feature, new API, experiment, documentation or various) for each entry.
  • Reword the title properly so it reads similarly for all entries (same format). A lot of PR names are not worded properly
  • Gather related items together using sublists (a11yAccessibility Accessibility (commonly shortened to a11y) refers to the design of products, devices, services, or environments for people with disabilities. The concept of accessible design ensures both “direct access” (i.e. unassisted) and “indirect access” meaning compatibility with a person’s assistive technology (for example, computer screen readers). (https://en.wikipedia.org/wiki/Accessibility), several enhancements to the same block….)
  • Gather PR links in the same Changelog entry if a PR fixes a regressionregression A software bug that breaks or degrades something that previously worked. Regressions are often treated as critical bugs or blockers. Recent regressions may be given higher priorities. A "3.6 regression" would be a bug in 3.6 that worked as intended in 3.5. introduced by another PR in the same release.

From that list @nadir created a script (which we should commit) that does the second step (and part of the third one) automatically. This is already a huge time saver but would be good to introduce more normalization/flows to PRs in order to avoid the need to do the rewording.

Benefits include: 

  • help make each release easier with less manual work involved even if some PRs still need to be documented by hand.
  • reinforces that all PRs need a label so none are left behind.
  • encourages organization around how labels are applied, titles are used, etc, which benefits more than just changelogs, but also searchability of the issue tracker more generally.

@nadir pointed out the script also supports skipping PRs that have a special label, in Woo it’s skip-changelog, which could be applied here if a PR is not meant to be in the changelog.

@youknowriad indicated one step needed to execute could be to match all categories (bug, enhancement, new feature, new API, experiment, documentation or various) with a “[Type] something” label.

@getdave noted updates to the PR merging documentation would need to occur about adding the correct labels before merging, and @mkaz pointed out it would be a good idea to simplify the current list of types, or create a new specific set. @youknowriad volunteered post meeting to filterFilter Filters are one of the two types of Hooks https://codex.wordpress.org/Plugin_API/Hooks. They provide a way for functions to modify data of other functions. They are the counterpart to Actions. Unlike Actions, filters are meant to work in an isolated manner, and should never have side effects such as affecting global variables and output. that list of types so Type could be equivalent to Changelog entry categoryCategory The 'category' taxonomy lets you group posts / content together that share a common bond. Categories are pre-defined and broad ranging..

Terminology Change — Align to Position

@getdave@matias raised a point about potentially renaming Block “Align” controls to “Position” and repurpose “Align” to mean something more akin to “Justify”.

To be clear, the new terminology could be:

  1. Position – how the container is displayed (wide, full-width, floated, etc).
  2. Align – for the distributions of elements within the container (left, center, space-between).

This would be a fairly significant change across the Editor and feedback is requested. Discussion is currently happening within PR 193686 for the Social Block but should become its own issue.

@matias noted alignments were used for position (floats, wide, and full) because of legacy reasons (WP had used alignleft, right and center for a long time). We distinguished between text alignment and block alignment, but it always left wide and full-width in weird places. Now we have newer blocks that need internal alignment controls (buttons, menus, social icons) and the inclination was to call this tool “justification”, but it’s also not the most intuitive. It seems the clearest and most meaningful names would be:

  • Position (floats, center, wide, full-width).
  • Text Alignment (left, center, right, justified).
  • Alignment (for flex-based left, center, space-between, etc).

These would need to be handled with care, though, to transition the components, APIs, classes, etc, without breaking anything.

Image Sizing

@paaljoachim noticed that the image in the Media & Text block becomes very huge on mobile. There should be a way to decide the size of the image used. This issue mentions image resizing PR 14483. Everywhere an image is used there should also be a way to resize it.