Jeffrey Paul 2:49 am on May 8, 2020
Tags: , WCEU   

Help needed —> Core team and WCEU Contributor Day

You may have seen update posts on WCEU’s plans on how to create an online Contributor Day this year (see posts from April 15th and April 24th). You may have also caught a reference to this in this past week’s devchat (see related summary post).

As part of the coming online/virtual WCEU, we’ve been asked to plan for how Core will handle an online Contributor Day.  The specific items we’ve been asked to consider:

  • Ensure our Getting Started at a Contributor Day handbook page has been updated as necessary
  • Ensure new contributor meeting happens between 25 May and 3 June, alerting the WCEU Contributor Day team via comment
  • Record a video intro about the Core team, similar to the live intros usually given in-person
  • Confirming list of good-first-issues and experience-issues for Contributor Day
  • Identifying 2+ experienced contributors to help facilities during Contributor Day
  • Plan for a live intro session at the beginning of Contributor Day

So I’m looking to you all to help here: who can help cover any of these tasks and help during the actual WCEU Contributor Day event? Please comment on this post noting which of the bulleted needs above are items you can assist with, thanks!

#contributor-day, #wceu

Jeffrey Paul 3:21 am on May 15, 2020
Tags:   

Core Team Reps: Submit Your Votes

In April we opened up nominations for new Core Team Reps to replace myself and @helen. Nominations have closed so now its time for voting!

You can find the poll below. Since we’re aiming for two reps to be elected this time, you can select up to two people to vote for.

What Are Team Reps?

In the WordPress open source project, each team has on average one or two representatives, abbreviated as reps.  Some teams have more than two, but for the sake of sanity sticking with two for now keeps things simpler.  And for the historians out there, the role goes way back to 2012.

Historically with the Core team, the team rep duration was around a year, though some reps stuck around longer if there was a particularly good fit.

Anyone who serves as a “team rep” is responsible for communicating on behalf of the Core team to the other contributor groups via weekly updates, as well as occasional cross-team chats.  Reps are also consulted on Contributor Day, helping find someone within the Core team attending an event who can help lead a Core table.  Full details on the Team Rep role is on the Team Update site.

It is not called “team lead” for a reason.  While people elected as team reps will generally come from the pool of folks that people think of as experienced leaders, remember that the team rep role is designed to change hands regularly.

This role has a time commitment attached to it.  Not a huge amount, but in my experience, it’s at least one hour a week.

Here are the main tasks:

  • Writing regular Core team recaps and posting it in Updates
  • Keeping an eye on the moving parts of the team to be able to report for quarterly updates (example)
  • Occasionally helping release leads with devchat agenda posts, chats, and summaries

More details on coordinating devchat are available in the Core handbook.

Over the year, the team might decide to add one or two people to help: some teams have up to five, six people, depending on how much work there is. For now, we’re going to be electing two team reps and, if the need arises later in the year, we can elect further people to serve in this role.

Ok then… let’s get us two new reps!

Where Can I Vote?

You can vote in the public poll here. You can vote for up to two people at the same time, but once you have submitted your vote you won’t be able to vote again.

If you have any questions, please feel free to ask in the comments.  I will be happy to reply (or look to past team reps for input)… thanks!

This poll will remain open until Thursday, May 28, 2020, after which team reps will be selected based on the votes received.

#team-reps

Mary Baum 4:32 am on May 14, 2020
Tags:   

Dev chat summary: May 13, 2020

@chanthaboune led the chat on the standard agenda.

Announcements/Highlighted Posts

Gutenberg 8.1

@youknowriad announced the minutes-old release of Gutenberg 8.1 and linked to the changelog.

Check out the full release post here.

WCEU Contributor Day

@jeffpaul pointed the group to this WCEU Contributor Day post and asked for volunteers to help on the day and beforehand.

@marybaum volunteered to do a video about contributing to Core in ways other than code, and the group asked her to please keep it brief. She promised it will be no more than a minute long.

@clorith is doing a video that focuses directly on code contributions.

@sippis posted this link to the full Contributor Day P2 and has made herself available for questions. @jeffpaul and @chanthaboune did as well.

Core Rep Elections

@jeffpaul reminded the group that May 14 is the deadline for nominating prospective Core Reps. These are very specifically not lead developer roles — they are roles that represent the work and interests of the Core team to other teams working on the project and to folks outside it as well.

See more in Jeff’s post here, including nominations and how voting will work.

Full-site editing outreach beta

Because the best things come in sets of three, @chanthaboune announced that May 14 is also the deadline to join the Full-Site-Editing outreach beta that she’s putting together.

Fill out the form and get all the details here.

Auto-Updates Feature Plugin

@audrasjb and @azozz updated the group on the status of Auto-Updates for Themes and Plugins, which as a feature plugin is at v.0.8.

The big news is the Core merge ticket, which is #50052, and its first patch, courtesy of @pbiron. As @audrasjb put it, “It’s a pretty big patch!”

Then he laid out the plan for the feature plugin:

Now, we’ll update the plugin with a PR that will deactivate the plugin when running the WordPress 5.5 / trunk to avoid conflicts.
Then, we’ll release version 0.8 of WP Auto-updates Feature plugin.

@audrasjb

Upcoming Releases

Major release: WordPress 5.5

@chanthaboune told the group she had a few more things to add to a 5.5 planning post; it is up here, and as of today we are kicking off the Countdown to Beta.

Pending further input, beta will be July 7, eight weeks from right now.

@chanthaboune noted in the chat that she’s still pulling together the Release Squad, adding, “But I wanted to see if anyone had volunteered for the release squad already that I might have missed.”

@marybaum and @whyisjake each, as they said, “volunteer formally, if not implicitly, . . ” to fulfill the roles they have in the immediate past.

With a wry emoji smile, @sergeybiryukov volunteered to reprise his tech-lead role as well.

Minor release: WordPress 5.4.2

@audrasjb referred to this list of 14 tickets in the 5.4.2 milestone. One ticket in particular caused concern in the group (Which one? You’ll see when you click on the list!)

So @whyisjake volunteered to lead a point release for mid-June. @audrasjb volunteered to help with all the things.

Open Floor

There were no specific calls from component maintainers, so the group moved on into Open Floor.

A request for eyes on a ticket

@apedog asked for some feedback on ticket #48223.

@jeffpaul noted almost immediately the ticket touches a component—Rewrite Rules—that at the moment has no formal maintainer. But then he wondered aloud if @sergeybiryukov and @asif2bd, who maintain the parent component Permalinks, could take a look.

Of course, @sergeybiryukov agreed.

Accessibility plans for 5.5

@audrasjb transitioned from that ticket into his accessibility update. Here’s what he and his squad are planning for 5.5:

Alternative WP List Tables views (work started on Trac)

Accessible color schemes (work started on GitHub)

Refine/replace the upper-right WP-Admin fly-out menu (work started on Trac)

And of course all the other tickets/bugs in the milestone

@chanthaboune: sabbatical planning

Josepha reminded the group she’s heading out on June 8, and we won’t see her back until September.

She pointed to a post that shows who to ask which questions, based on the topic and people’s areas of expertise.

A forum post about HTML entities

@joyously brought this forum post to the group, starting a lively discussion about sanitizing and escaping HTML in blocks and the Classic editor.

Finally …

Remember those May 14 deadlines. By now, that’s today! And watch this space for news on Core reps, the release squad and more.

#devchat

carike 12:16 am on May 14, 2020
Tags: , , , , , WCEU 2020, WordCamp Europe Online 2020   

Privacy Office Hours Minutes 14 May 2020 Plans for WCEU Contributor Day

Mission for WCEU Contributor Day:

Make Privacy Actionable.

Working groups:

There will be two working groups:
– Coding working group (coordinated by @garrett-eclipse);
– Non-coding working group (coordinated by @carike).

Pre-event office hours:

– 3 June 2020 at 10:00 UTC;
– 3 June 2020 at 19:00 UTC.

Pre-event office hours are to help onboard new contributors.
This primarily involves making sure that they have access to the tools necessary for the day.

Tools:

Slack:
Privacy Policy: region-specific at https://slack.com/intl/en-us/privacy-policy
Terms of Service: region-specific at https://slack.com/intl/en-us/terms-of-service/user

StreamYard:
Privacy Policy: https://streamyard.com/resources/docs/privacy/
Terms of Service: https://streamyard.com/resources/docs/tos/
We will be using StreamYard, as a number of experienced contributors in core-privacy have expressed an unwillingness to use Zoom due to privacy considerations.

YouTube:
Privacy Policy: https://policies.google.com/privacy
Terms of Service: https://www.youtube.com/t/terms

Core Trac (coding working group):
Privacy Policy: https://wordpress.org/about/privacy/

GitHub (coding working group):
Privacy Policy: https://help.github.com/en/github/site-policy/github-privacy-statement
Terms of Service: https://help.github.com/en/github/site-policy/github-terms-of-service

How to participate:

As a host:
If you are interested in hosting one or more topics, please comment below.
You can contact @carike on Slack if you would like more information.

As a guest via StreamYard:
You DO NOT need to register a StreamYard account in order to enter the stream as a guest.
You DO NOT need to download any program in order to use StreamYard. It is an in-browser solution.
You DO NOT need to appear on-screen if that is not something you are comfortable with. An audio-only option is available. We’re going to be using a very practical approach, so I’m going to be screen-sharing most of the time anyway.
We will provide new contributors with instructions on joining StreamYard as a guest via e-mail.
Instructions can also be found here: Guest Instructions: https://streamyard.com/resources/docs/guest-instructions/
We will provide new contributors with a link to join the stream via Direct Message (DM) on Slack, as there can only be six contributors “onscreen” (or via audio) at any one time (i.e. two hosts and four new contributors), with up to four additional new contributors in the “waiting room”.

As a guest via YouTube:
You DO NOT need to register an account with YouTube in order to watch the stream.
You DO need to register an account and be logged in to YouTube in order to participate in the live chat.
StreamYard supports integrating live chat messages from YouTube.
This will allow for more real-time input and also allow participation among those who do not want to use audio, or appear onscreen.
We are trying to recruit experienced contributors to help moderate the YouTube live chat to ensure compliance with the WCEU Code of Conduct, as well as to highlight any questions, comments and suggestions to the hosts.
Please comment below if you are able to help with YouTube live chat moderation.
You can find a copy of the WordCamp Europe Online 2020 here: https://2020.europe.wordcamp.org/code-of-conduct/

Via Trac (coding working group):
You DO need to register an account with WordPress.org in order to comment on Trac tickets.

Via GitHub (coding working group):
You DO need to register an account with GitHub in order to create / comment on issues or to create / comment on Pull Requests (PRs).

On the day:

The coding working group will participate via Slack, Core Trac and GitHub.
@garrett-eclipse is going through the list of privacy-related tickets to mark them with the “good first bug” tag where applicable.
For the more adventurous, there is the option to contribute to “help wanted” tickets for the next major release (WordPress 5.5.).
Contributor Day officially runs from 13:00 – 18:00 UTC, but Garrett will advise on his schedule and availability in due course.

The non-coding working group will have two two-hour sessions, with the possibility of a third.

13:00 – 15:00 UTC
How to market without destroying user privacy (working title only).
Hosts: @carike and @jonoaldersonwp
During this session, we hope to identify online marketing best-practices that can be implemented even when users have opted-out (or not opted-in, depending on the jurisdiction) to being tracked with the view of creating actionable Trac tickets and / or to provide a resource for content marketing.
Jono is “special ops” at Yoast SEO and we are very excited to have him participate.

16:00 – 18:00 UTC
A case study in the application of the Privacy Workflow Document and the Disclosures and Permissions (DPT) tabs.
Hosts: @carike and @pepe
In this session, we will be attempting to harmonize the Privacy Workflow Document and the Disclosures and Permissions (DPT) tabs and apply them practically to a specific plugin [still to be selected – please comment below if you are a plugin author with a plugin hosted in the WordPress.org repository and you’d like to participate].
The desired outcome for this session is an action plan for an education drive among plugin and theme authors regarding the proposed disclosures.json file.
Pepe has previously presented at WordCamp, is very involved with the #core-privacy team and was helped to create the draft Privacy Workflow Document. His insight will be invaluable to this session.

19:00 – 21:00 UTC [not finalized]
Identifying and reviewing possible tools that can help users be safer and more private when contributing to WordPress.org
Hosts: @carike and [help wanted – please comment below]
In this session, we will be looking at the privacy policies, terms of service and reputations of various services with the view to make recommendations to WordCamp organizers, as well as #forums and #meta when choosing services to facilitate contributor participation.
Thus far, we will be looking at:
– streaming / meeting services (e.g. Zoom);
– project management services (e.g. Trello);
– photo sharing services (e.g. imgur.com);
– code snippet / pastebin type services.

License:

We will be using the Creative Commons Attribution-ShareAlike 4.0 International (CC BY-SA 4.0) license for the non-coding work group:
https://creativecommons.org/licenses/by-sa/4.0/legalcode

Contributions to the WordPress.org code are licensed in terms of the General Public License (GPL) version 2 or later:
https://www.gnu.org/licenses/old-licenses/gpl-2.0.html

Slack logs:

You can view the Slack logs here:
https://wordpress.slack.com/archives/C9695RJBW/p1589396619341400
In order to view the logs, you will first need a WordPress.org account: https://login.wordpress.org/register
You will then need to register a Slack account: https://make.wordpress.org/chat/

Change log:
14 May 2020 at 14:15 UTC – @carike added GitHub information.
14 May 2020 at 17:45 UTC – @carike updated formatting in the Slack links.
16 May 2020 at 11:35 UTC – @carike switched out the non-coding session starting at 16:00 UTC, as Pepe has agreed to co-host.

#contributor-day, #privacy, #wceu-2020, #wordcamp-europe-online-2020

Josepha 10:53 pm on May 13, 2020  

WordPress 5.5 Planning Roundup

There have been some scattered discussions about making some shifts to the way that we manage releases. I’m open to suggestions on the timeline below if I have misunderstood anything!

As was suggested in the WP5.3 debrief, the cycle for WP5.5 has a longer alpha period (clocking in at ~126 days, one week less than WP5.3). As was discussed in the core committer Slack channel and subsequently suggested by @francina, this cycle also has a shorter RC period (clocked in at 14 day, two weeks shorter than WP5.3 but one week shorter than WP5.4).

Proposed WordPress 5.5 Schedule

These are my best guesses at the milestones, based on what I was able to find of the discussions:

  • Alpha: 3 March, 2020 trunk is open for 5.5 alpha contributions
  • Kickoff: 13 May, 2020 (that’s this post!)
  • Betas: 7 July, 2020 (8 weeks from kickoff)
  • Release Candidates: 28 July, 2020 (3 weeks from beta 1)
  • General Release: 11 August, 2020 (2 weeks from release candidate 1)

Proposed WordPress 5.5 Scope

The main goal for 2020 is full site editing via Gutenberg. For WP5.5 the following features are in the suggested roadmap:

  • Update WordPress Core to include current releases of the Gutenberg plugin.
  • Navigation menus block in Core.
  • Automatic updates for plugins and themes in Core.
  • Block directory in Core.
  • XML Sitemaps 
  • Lazy Loading 

Also in that roadmap are a few hopeful items. Getting these into the Gutenberg plugin would be a great goal!

There were also a collection of hoped-for tickets raised on my earlier post as well as a number from component maintainers. I ended up with some outstanding questions on those, but should have everything I need soon.

Proposed WordPress 5.5 Leads

This area is intentionally incomplete. I’ve got some more confirmations/discussions I’m working through!

  • Editor Tech:
  • Editor Design:
  • Core Tech:
  • Docs coordinator:
  • Marketing/Release Comms:
  • Triage PM:
  • Release coordinator:

#5-5 #planning

Jorge Costa 9:00 pm on May 13, 2020
Tags: ,   

What’s new in Gutenberg? (13 May)

Gutenberg 8.1 release mostly contains developments/enhancements on experimental screens, bug fixes, and performance improvements.
It also contains some new features available on the general editor screens, described bellow.

New block pattern features

Gutenberg 8.1 brings pattern search to make it easier to insert the desired patterns and a new pattern: the testimonials.

Copy block action

The copy block action is a small quality of life improvement for touchscreen users or users who don’t use keyboard shortcuts. Gutenberg 8.1 adds a button to the collapsed block actions (next to duplicate, etc.) to copy the selected block(s). The feature is quite similar to the “Copy all blocks” but then for the selected block.

8.1 🇹🇷

New features

  • Pattern search (21944)
  • Testimonials block pattern. (20894)
  • New Transforms:
    • Embed blocks into Paragraph blocks. (17413)
    • Code to HTML block and the opposite. (21779)
  • Add copy action to the blocks. (22214)

Enhancements

  • Implement Block Navigator selection on the Nav Menus page. (22017)
  • Write block patterns in PHP to allow i18n. (21946)
  • Post title: handle paste as blocks. (21758)
  • Clear Publish Date Button. (20914)
  • Add gap between nested submenus. (22227)
  • Block Library: enhance the author’s block. (19894)
  • Add “black” and “white” color options to the default color palette. (22082)
  • Light blocks: social links. (22078)
  • CustomSelectControl: set aria-hidden to empty option list. (21298)
  • Add some more g2 icons. (21825)
  • Allow the column block in the inserter. (20502)
  • Delete menus in nav menus experimental screen. (21486)
  • Visual and experience improvements to existing sub-navigation flow. (22107)
  • Reduce font-size and line-height of “it’s time”. (21627)
  • Template Loader: Introduce get_template_hierarchy(), drop gutenberg_template_include_filter(). (21980)
  • Make parts of the BlockNavigationList overridable using slots. (21948)
  • Change the color alpha input step to match the slider step. (21953)
  • Navigation: fallback for undefined orientation. (22057)
  • Remove the subscription button from the blog template. (22129)
  • Move the Entities Saved States from Modal to Sidebar. (21522)

API Changes

  • Update the Patterns API to avoid ambiguity. (21970)
  • Expose the registered pattern slugs in get_all_registered. (21619)
  • Fix doc-building pre-commit API hook issue. (22116)
  • REST API: Block directory – Typecast author_block_count as integer. (17594)
  • Block API: Block Context: Filter content, prepare attributes at render, pass a block to render. (21925)

Experimental

  • Add undo-redo UI to edit-site and edit-widgets. (21955)
  • Light blocks: site title. (22069)
  • Update: Use EntityProvider on the widget area. (22008)
  • Site editor:
    • Extract gutenberg_find_template_post helper. (21959)
    • Fix default editor background. (22182)
    • Refactor close button slot. (22179)
    • Make close button replaceable. (22001)
    • Add home icon to template switcher. (22004)
    • Updated template content. (22044)
    • Fix spelling mistake. (21991)

Performance

  • Reduce re-renders from block nodes context. (22134)
  • Move memo() from BlockStyles to BlockPreview. (21993)
  • Avoid rerenders of the entire BlockInspector when block attributes change. (21990)
  • Optimize BlockStyles by using hooks and React.memo (instead of HOCs). (21973)

Bug Fixes

  • Popover: Fix closest().parentNode null error. (22264)
  • Correct color palette in color settings. (22138)
  • Remove import of inexistant component. (22130)
  • Build Tooling: Run packages build before lint. (22088)
  • RangeControl: Fix number input change interaction. (22084)
  • Fix entity selection through save panel. (22011)
  • ESLint Plugin: Relax check for i18n-text-domain rule. (21928)
  • Block Library: Fix React does not recognize isSelected prop in Spacer block. (21924)
  • Reinitialize the iframe after the parent block is moved around. (21916)
  • Configure the navigation editor with correct __experimentalFetchLinkSuggestions. (21873)
  • Create the proper shortcode on paste. (21864)
  • Refactor FontSizePicker component. Fix bug on undo. (21757)
  • Move caret to the end of pasted content. (21755)
  • Embed: use the same SmugMug URL regex as the core. (21744)
  • Navigation block: use new icon in placeholder. (21713)
  • Fix Template Part placeholder preview. (21623)
  • Restore the missing background color on the nested submenus. (22228)
  • fix: [#21777] Prevent focusing of FireFox address bar. (22215)
  • Fix flaky test in rich text. (22202)
  • Fix flaky test: tag “target” attribute. (22200)
  • Fix extra tab stop on Modal component. (22063)
  • Writing flow: fix vertical arrow nav in table (and generally grid). (22105)
  • Gallery block / media-placeholder – Preserve changes made while upload in progress. (19134)
  • Add missing dependency. (22086)

Tooling

  • Build Tools: Validate package-lock.json for “resolved” errors. (22237)
  • Build Tools: Disable ESLint no-console for bin directory. (22033)
  • Build Tools: Changelog: Normalize entry to end with period. (22010)
  • Add analyze-bundles script. (21827)
  • Add changelog generator script. (19866)
  • Add a method for publishing patches to the Lerna scripts. (21844)
  • Add additional e2e debugging option. (21845)
  • Replace espree with babel. (21853)
  • Update diff to 4.0.2 and work around tree-shaking issues. (21994)
  • Increase the severity of jsdoc/no-undefined-types. . (21942)

Code Quality

  • Block: move new props to hook. (22212)
  • Block: avoid useLayoutEffect. (22108)
  • Try: Reduced specificity base block margins. (22051)
  • Update the audio and video blocks to use a light wrapper in the editor. (22028)
  • Remove unused animation lingering in paragraph file. (22020)
  • Columns. Remove the top and bottom margin from individual column blocks. (22018)
  • Try better inserter toggle styling. (22016)
  • Block Editor: Rename block context in BlockListBlock. (21922)
  • Remove duplicate CopyHanddler. (21817)
  • Types: Restore element, icons, primitives types. (21781)
  • Convert core toolbar buttons into ToolbarButton. (20008)
  • Block Directory: Add end 2 end tests. (20023)
  • ClipboardButton: use hooks. (22220)
  • ClipboardButton: remove wrapper span. (22218)
  • Block Library: Update FSE blocks to use block context. (21696)
  • Group: Zero out the intrinsic margin set to every block in the editor. (22209)
  • Unset the inherit for links. (22160)
  • Template Loader: Get rid of _wp_current_template_part_ids globals. (22143)
  • Block Library: Post Author: Reference attributes by argument. (22114)
  • Remove pass by reference of the $scripts and $styles attributes in client-assets.php. (21987)
  • Use optional chaining, optional catch binding. (21967)
  • Extract block mover buttons so that they can be individually imported. (22122)sss

Documentation

  • Scripts: Mark env script as deprecated. (22158)
  • Docs: Use InspectorControls from wordpress/block-editor. (22153)
  • Fix bundle analysis change location in the changelog. (22136)
  • Documentation: Improve the way CHANGELOG files are maintained. (22126)
  • ESLint Plugin: Add missing rules to root README. (22042)
  • Fix props, in example, code for Edit Post module. (21976)
  • Document e2e test command options. (21962)
  • Add an example for how to choose a style variation for a block variation. (21927)
  • Add documentation for onSelectURL property. (20799)
  • Document the old patterns API deprecation. (22177)
  • Coding Guidelines:
  • Document JavaScript language support commitment. (22030)
  • Add “gotchas” section about ES2020 optional chaining. (22029)
  • Recommend function components. (22090)

Various

  • Expose presets declared via add_theme_support in global styles. (22076)
  • Update is-promise package to the latest version. (21940)
  • Blocks: Register FSE blocks if the experiment is enabled. (21536)

Mobile App

  • Add missing RTL support for some mobile components. (21502)
  • Remove separatorType prop from TextControl, RangeControl… (21365)
  • Color settings. (21326)
  • Global styles provider. (21637)
  • Update existing templates to use new blocks. (21857)
  • Enable pullquote block. (21930)
  • Merge release branch back to master for v1.27.1. (22234)
  • Wrap button blocks with buttons blocks in page templates. (21939)
  • Components: Create a separate .native entry for ToolbarItem. (22229)

Performance Benchmark

The following benchmark compares performance for a particularly sizeable post (~ 36000 words, ~ 1000 blocks) over the last releases. Such a large post isn’t representative of the average editing experience but is adequate for spotting variations in performance.

Version Loading Time KeyPress event (typing)
Gutenberg 8.1.0 10.88s 43.61ms
Gutenberg 8.0.0 13.30s 42.97ms
WordPress 5.4 10.80s 52.87ms

#core-editor, #editor

annezazu 5:19 pm on May 13, 2020
Tags: , , , ,   

Editor Chat Summary: 13th May, 2020

This post summarizes the latest weekly Editor meeting (agenda, slack transcript). This meeting was held in the #core-editor Slack channel on Wednesday, May 13, 2020,14:00 UTC and was moderated by @andraganescu.

Gutenberg 8.1.0

Gutenberg 8.1 RC was released on May 11th and is on track for a final release. 8.1 is focused on performance improvements, bug fixes and multiple enhancements around several areas of the editor and the experimental screens/features. Outside of those focuses, there are also new features like new transforms, pattern search, and a new testimonials pattern.

Weekly Priorities

There was limited discussion on weekly and monthly priorities. @andraganescu noted that the new navigation menu screen is coming together! Overall though, Full Site Editing (FSE) is a major focus right now and can be followed here with the overall plan shared here.

Task Coordination

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

@nosolosw

  • Main focus has been “Global Styles”. Currently, iterating on some framework tasks that need to be to unlock before resuming work on the UI. This will be the focus for this week too.

@aduth

  • Working on some documentation and framework-level improvements, largely summarized in this slack convo.
  • Refreshing and splitting off work around renaming block categories.
  • Next up, continuing work on renaming block categories plus follow-up work around block context.

@youknowriad

  • Did two zoom chats to help contributors (one in #core-editor, one in French WordPress slack).
  • Trying to land categories support for patterns.

@nrqsnchz

@retrofox

  • Made progress in the Tips approach. It’s now possible to register tips defining the scope, descriptions, and other parameters.

@earnjam

  • Handling some PR reviews to help with triage starting with the list of non-draft PRs with no review, less than 2 comments, and sorted by least recently updated to try to find anything that has slipped through the cracks.

@mapk

  • Spent time triaging issues.
  • Search block enhancements.

@itsjonq

  • Continuing to add features to Cover block via new control UIs (“Design Tools”). In doing so, also building a set of incredibly robust and feature rich control primitives (e.g. Input).
  • Longer termer goal would be to (hopefully) refactor/replace existing controls within Gutenberg with these ones. These components would of course be available for block/plugin authors as well, enriching the UI experience of the Gutenberg ecosystem as a whole.

@vindl

  • Working on allowing extensions/replacements of editor close button which is part of this issue. It’s already merged for the site editor, and now I’m looking to expand it to the post editor too.
  • After the above work wraps up, will return to site editor UI tasks. 

@michael-arestad

  • Working on template part creation/manipulation design patterns. Right now, exploring how they might work as sections. This could be really slick when building templates.
  • Continuing on this path this week and will likely spin up some zooms if anyone wants to help or just watch! Links will be shared in #design.

@sageshilling

  • Working on the image and gallery blocks.

@andraganescu

  • Working on the navigation screen– just merged menu location management.
  • Will continue to work on various issues on this project for the next week.

@zieladam

Working on the experimental navigation screen, in particular:

Open floor

Do we instead of listing packages and versions, need to list components and versions? Raised by @paaljoachim.

This discussion point was raised in reaction to a comment from @clorith in this trac ticket on adding Gutenberg plugin version information to the Site Health section. Right now, this trac issue needs feedback to keep the issue moving. It was agreed that there’s no easy solution to this partially because WordPress versions includes features and bug fixes of various versions of Gutenberg. This makes handling bug reports tricky for example.

Next step: Taking the discussion back to the track ticket!

Do we need to apply a max height for the style placeholders in the inspector? Raised by @munirkamal.

The problem right now is that placeholders need to have a preview so if the block is quite large the the preview is too. @matveb chimed in to say that previews are loading example content now so this decision is up to the block author. However, if an example is not provided it falls back to actual block content which is where a max-height could be useful.

Next step: A “Needs Design” Label was added to the issue for design to explore further.

What time and day would work for the discussion about full-site editing and the core customize component? Raised by @dlh.

The original proposed date and time was 20:00 UTC on May 25th but this time may not work well for the people working on Full Site Editing. @youknowriad suggested meeting more around 15UTC/16UTC but wants to hear from others. Tied to this, @aduth noted that May 25th is Memorial Day in the United States which

Next step: If you’re interested in attending this meeting, please share in the comments below what time might work best. Notes will be taken and posted either way if you can’t make it.

Can we add a block ID to each block that is unique and stable to help connect server data to client data? Raised by @sageshilling.

This came up as part of work done on the image and gallery blocks (full context here). There have been various discussions about this historically in the early days of Gutenberg. These discussions always concluded that while there is a need for this from time to time we don’t want to pollute markup and/or we don’t want to keep two separate things in sync. Before discussing anything technically, it was agreed that a case needs to be made for why it should go in core and why extension-based solutions are not apt.

Next step: @sageshilling will collect use cases and details in a post on meta to propose this idea.

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

Lara Schenck 1:52 pm on May 13, 2020
Tags: ,   

CSS Chat Agenda: 14th May…

CSS Chat Agenda: 14th May 2020

This is the agenda for the upcoming CSS meeting scheduled for Thursday, May 14, 2020, 5:00 PM EDT.

This meeting will be held in the #core-css channel in the Making WordPress Slack.

If there’s any topic you’d like to discuss, please leave a comment below!

  • CSS audit status update
  • Color Scheming Updates
  • WCEU Online Contributor Day – Make post
  • wordpress/postcss-plugins-preset – Slack post

#agenda, #core-css

Jb Audras 10:52 pm on May 12, 2020
Tags: , , , ,   

Auto-updates feature meeting summary: May 12, 2020

These are the weekly notes for the WP Auto-updates team meeting that happened on Tuesday May 12, 2020. You can read the full transcript on the core-auto-updates Slack channel.

Reminder, WP Auto-updates Feature Plugin is developed on GitHub and is available for testing on WordPress.org plugins repository.

Update on core patch

@pbiron is in charge of the core patch. It should be ready around the middle of this week. Paul asked whether it’s better to do a pull request against wordpress-develop GitHub repository or a diff file on Trac.

@azaozz answered both would work, and have different pluses and minuses:

  • Pull requests can be reviewed in inline comments, but are harder to modify by different people.
  • A diff file would need to be applied to a svn checkout before testing, but easier to iterate (to make new diffs)

Paul will send a diff file.

WP auto-updates version 0.8.0

Here are the expected steps for the core merge:

  1. Publish the diff file on the related Trac ticket (#50052)
  2. After merge details are known, update Pull request #123 – Self-deactivate the plugin after the functionality has been merged to core
  3. Release WP Auto-updates version 0.8
  4. Commit the Trac diff file to WordPress Core

@azaozz noted that releasing version 0.8 after the diff is available on Trac is needed to make sure the plugin can self deactivate once the diff file is merged into WordPress core. The check in version 0.7 doesn’t actually work with the patch, because the name of the function it is checking changed in the patch

The plugin’s options should also be deleted from WordPress installs once the plugin is uninstalled by sites owners. @audrasjb opened pull request #125 to handle that.

The team noted the feature plugin reached 900+ active installs. 77% are running version 0.7, 12% are running version 0.6 and 11% are running versions 0.6.0 or less.

@whyisjake also implemented prettier on the plugin. It allows to run CSS/JS lint check, using npm test , and to fix linting issues using ESLint --fix option.

Open floor

@azaozz shared some thoughts about keeping some stats on successful/failed autoupdates, on the WordPress.org API side. It’s not a blocker for merging and can be added later. The idea is to potentially have anonymous/aggregated stats per plugin/theme. This is also related to the Tide project, which can use those stats to determine how “safe” an update may be.

@audrasjb asked if it’s directly related to this feature or if it should be handled in a separate ticket/project. For @azaozz, it is part of plugins and themes auto-updates, but it can be a separate Trac ticket.

@pbiron asked if we were talking about stats on the results of auto-updates, or about user preferences for what should be auto-updated (since whether an auto-update is attempted can be controlled by other plugins, such as Easy Updates Manager, etc). Andrew answered that it may be both.

@audrasjb asked what would be the main benefit for the end user? Having prompts to alert on “not recommended” updates? @azaozz doesn’t think it would be a direct communication but an auto-update may be eventually stopped/postponed if there are many failures.

@apedog wanted to mention a version-rollback feature for plugins. For them, it would become relevant as more installations start using WP Auto-updates feature plugin. @audrasjb answered it should eventually be introduced independently of auto-updates feature as it’s not only related to this type of updates mechanism. @apedog pointed out that breakage occurring from a manual update gives the user immediate feedback. An over-night auto-update (especially if multiple plugins/themes were updated) could make debugging much harder. @audrasjb added that the best way to move this independent project forward is to open a ticket on Trac if it doesn’t exists yet. @sergeybiryukov added that WP Core do perform a rollback if a background core update fails (enabled for minor versions by default), that might be helpful when looking into implementing this for plugins and themes too.

@apedog also asked whether WP Auto-updates log the previous version vs new version? For example, for a user encountering breakage from an auto-update. Site breakage can occur even on successful updates – simply due to conflict. @audrasjb answered there is no such log mechanism in core, even for manual updates.

@pbiron asked @audrasjb if Pull request 121 – Add help tabs on update-core, plugins, and themes admin screens is going to be ready on time for version 0.8.0. @audrasjb is on it, but it will probably needs copy review.

The team agreed Help Tabs will be handled separately from the initial core patch, to give it time for copy review.

#auto-update, #core-auto-updates, #feature-plugins, #feature-projects, #feature-autoupdates

Andrew Duthie 8:52 pm on May 12, 2020
Tags: ,   

JavaScript Chat Summary: May 12, 2020

Below is a summary of the discussion from this week’s JavaScript chat (agenda, Slack Transcript).

Have a topic for discussion for the next meeting? Leave a suggested edit on next week’s agenda.

@wordpress/scripts CSS support

(Slack conversation)

Pull request: https://github.com/WordPress/gutenberg/pull/21730

Discussion topics:

  • There was surprise that this wasn’t already supported.
  • The pull request will add a new package @wordpress/postcss-plugins-preset, which would provide a default set of WordPress’ preferred PostCSS plugins configuration.
    • Similar to @wordpress/babel-preset-default, @wordpress/jest-preset-default, @wordpress/prettier-config
  • Question: Was there any consideration for CSS-in-JS? (styled-components)
    • Needs clarity on desired end-goal
    • Still valuable for plugin authors regardless, if it’s easy enough feature to simply not use if they’d prefer to use an alternative approach.
  • Advantages: Dead code elimination and bundle splitting for CSS
  • It was suggested to request feedback from the CSS group

Action items:

@wordpress/create-block third-party templates

(Slack conversation)

Pull request: https://github.com/WordPress/gutenberg/pull/22175

Discussion topics:

  • It could help to support flexibility of third-party templates, in order to alleviate pressure for first-party templates to support all features.
  • Concern: Is it the purpose of the tool to support third-party templates? If so, why not use something like Yeoman?
    • Counter-point: It’s not unlike Yeoman, but utilizes NPM’s own npm init <initializer> functionality. They’re comparable, but it’s not necessarily a criticism.
    • Suggestion: Focus less on third-party template flexibility, more on first-party “knowledge of blocks”, including additional commands and customizations.
    • Point of contention: Should customizability come from third-party templates, or first-party support?

Action items:

Block Identifier

(Slack conversation)

Topic: Should the block editor provide a stable way to connect server and client data? For example, associate posts to blocks using post meta.

Additional context can be found in the agenda document.

Discussion topics:

  • Question: Is this suggesting some value saved in post meta which corresponds to individual blocks of a post?
    • Answer: Yes
  • Question: What’s the use-case? Is there an example?
    • Answer: It’s needed for the image block.
  • It might be something which is fine to have an ad hoc implementation specific to one or a few blocks, if it’s not a common requirement.
  • Concern: Duplicating data can risk desync (see related post)

Action items:

  • Create an issue which describes the use-case and requirements (Owned by: @sageshilling)

Open Floor

Miscellaneous Updates

@aduth shared a number of updates from the past week:

The coding guidelines documentations we discussed last week are most all merged:
https://github.com/WordPress/gutenberg/pull/22090
https://github.com/WordPress/gutenberg/pull/22030
https://github.com/WordPress/gutenberg/pull/22029

That last one prompted the idea for a new ESLint rule, currently in progress, but potentially blocked on the fact that there appears to be legitimate cases for wanting the “gotcha” behavior.
https://github.com/WordPress/gutenberg/pull/22041

Now pinning .nvmrc to specify Node version in Gutenberg, to avoid issues when running on older branches:
https://github.com/WordPress/gutenberg/pull/22236
(As far as I know, Core does the same)

ESLint 7.0 was released the other day, which notably includes an interesting feature to allow comments within the inline configuration tag
https://eslint.org/blog/2020/02/whats-coming-in-eslint-7.0.0
Example:
/* eslint-disable no-new -- this class has a side-effect in the constructor. */
Very relevant for this previously-suggested rule proposal: https://github.com/WordPress/gutenberg/pull/16795

@sageshilling shared features announced in Next.js 9.4.

News Roundup

This roundup contains a few links for Gutenberg and JavaScript related news curated (and commented on) by @nerrad.

#core-js, #javascript

Jb Audras 4:25 pm on May 12, 2020
Tags: , , , ,   

Auto-updates feature weekly meeting agenda – May 12th, 2020

Next meeting is scheduled on Tuesday May 12, 2020 at 17:00 UTC and will take place on #core-auto-updates Slack channel with the following agenda:

  • Update on core patch
  • Feature plugin’s scope for version 0.8
  • Prettier implementation
  • Open floor: issues & PR / other topics

Got something to propose for the agenda? Please leave a comment below.

#agenda, #auto-update, #core-auto-updates, #feature-plugins, #feature-autoupdates