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 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 block UI 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 triage as the issues and PRs are getting out of control 
  • Reviewing some FSE PRs

@scruffian:

  • The site title block doesn’t work for non-admin users; to address this we need to make some REST API changes — please review #48885 (REST API: Add a route to read and update separate site settings) – WordPress Trac

@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 API 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 UX 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 (bug, enhancement, 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 (a11y, several enhancements to the same block….)
  • Gather PR links in the same Changelog entry if a PR fixes a regression 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 filter that list of types so Type could be equivalent to Changelog entry category.

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.