Editor chat summary: May 8

This post summarizes the weekly Editor meeting on Wednesday, 8th May 2019, 13:00 UTC held in Slack.

The agenda followed can be found here.

Volunteers for Note-Taking Requested

As there are not very many folks who are taking notes for the chat at the moment, volunteers were requested. @nosolosw, @andraganescu, and @jorgefilipecosta offered to help out.

WordPress 5.2

WordPress 5.2 was released! Thanks to everyone who helped!

@youknowriad noted that he wasn’t sure why all of these things weren’t highlighted in the release post, but updates include:

  • No more TinyMCE in blocks
  • 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. Management UIUI User interface
  • Performance more than doubled in async mode
  • All widgets ported to blocks
  • A lot of improvements to existing blocks (cover block with inner blocks, focal point picker,…)
  • Stability improvements
  • Zero-config scripts to help authors create blocks

AccessibilityAccessibility 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) Audit

The accessibility audit has been published. This is a great resource to improve the accessibility of the editor. Thank you to everyone that worked on it!

@andraganescu, @karmatosed, and @mapk attended the Accessibility chat to collaborate (recap was posted on the agenda post).

Design has done two triagetriage The act of evaluating and sorting bug reports, in order to decide priority, severity, and other factors. sessions focused on the report (the next is on Friday, May 10, 2019 at 14:00 UTC), and development has already started in fixing some of the issues found.

The project board can be found here, and issues are also being grouped into labels (like [a11y] Keyboard & Focus). There’s interest in solving all validated issues that were found.

Several folks expressed interest in an 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) focused WordPress releaseRelease A release is the distribution of the final version of an application. A software release may be either public or private and generally constitutes the initial or new generation of a new or upgraded application. A release is preceded by the distribution of alpha and then beta versions of the software., with the note that it would need to be a broader conversation with coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. + leadership.

@bemdesign mentioned, and others agreed, that while automation can help, a11y should ultimately be built into the process. Tenon, the company that ran the audit, provided documentation on how they tested.

Some recommended next steps included:

  • Aim for closing the project board by the end of May
  • Focus all triages until that can happen
  • Consider adding a column for deeper conversations / focuses and makemake A collection of P2 blogs at make.wordpress.org, which are the home to a number of contributor groups, including core development (make/core, formerly "wpdevel"), the UI working group (make/ui), translators (make/polyglots), the theme reviewers (make/themes), resources for plugin authors (make/plugins), and the accessibility working group (make/accessibility). issues for those
  • Dev-triage session focused on the board next week (Monday)
  • If you’re looking for an issue to tackle, take a look at this board first 🙂

Task Coordination

  • @nerrad:
  • @aduth has an initial pass of resizable columns to share
  • @andraganescu
  • @notnownikki
  • @joen is working with @kjellr on various ways to improve parent block selection.
  • @gziolo refactored a few core blocks to better follow the Block Registration 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. RFC. The Puppeteer upgrade uncovered a few unstable tests which they’re going to skip until the root cause is fixed.
  • @jorgefilipecosta
    • Working on fixes for the generic block editor and functionality missing from the widgets screen.
    • @noisysocks to help get the widgetWidget A WordPress Widget is a small block that performs a specific function. You can add these widgets in sidebars also known as widget-ready areas on your web page. WordPress widgets were originally created to provide a simple and easy-to-use way of giving design and structure control of the WordPress theme to the user.’s block editor prototype merged.
  • @mapk
  • @karmatosed
    • Running triages and unblocking anything a11y audit-wise.
    • Cleared out the ‘User Experience (UXUX User experience)’ label that was confusing things for design and becoming a bit of a lost label.
    • There will be a testing table at WCEU for 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/. Post to come soon with more details.
  • @kjellr
    • Working on improving child/parent block selection and this PR to make theme styles for the Group block easier to implement.
    • Then, back to Twenty Nineteen + Twenty Thirteen group block patches, with updates for these changes.
  • @nosolosw is working on the handbook migrationMigration Moving the code, database and media files for a website site from one server to another. Most typically done when changing hosting companies. to DevHub.
  • @danr is resuming work on the table block: PR for adding headerHeader The header of your site is typically the first thing people will experience. The masthead or header art located across the top of your page is part of the look and feel of your website. It can influence a visitor’s opinion about your content and you/ your organization’s brand. It may also look different on different screen sizes./footer rows ready. Did some explorations on keyboard navigation between cells, and will work on adding captions.

Note: Anyone reading this summary outside of the meeting, please drop a comment if you can/want to help with something.

Open Floor

@karmatosed asked if anyone would be interested in working with them on more detailed RC notes to be included in calls for testing.

@aduth raised a question about merge permissions.
“Is there a good sense of criteria for this to be granted? Or similar to core committercommitter A developer with commit access. WordPress has five lead developers and four permanent core developers with commit access. Additionally, the project usually has a few guest or component committers - a developer receiving commit access, generally for a single release cycle (sometimes renewed) and/or for a specific component. status, at discretion of leadership?”

Folks present seemed to be in consensus that this should be clarified, even if it’s only in terms of documenting general expectations.

Recommendations on criteria often included a number of contributions (committed PRs or other activities), ranging from 3-10 — with a note from @gziolo that Gatsby automatically adds access after one.

In closing, a quote from @andraganescu, “The thing with merge access is that as long as we have the triage/review/automated testing process the only thing you need is to prove some kind of good faith I guess”

Have thoughts on the above? Please leave a comment on this post!

The agenda for the next meeting, on 15 May 2019 at 13:00 UTC, is here; please add anything that you want to discuss.

#accessibility, #core-editor, #editor, #gutenberg, #meeting-notes