Dev Chat summary – January 22, 2020

@francina led our discussion from this agenda.

Announcements

The chat marked week 2 of th 5.4 release cycle.

@francina announced that @davidb has posted this bug-scrub schedule, which also lists regular design and editor triages. Remember, you can get serious props by hosting a scrub of your own — and you can pick the tickets to suit your own interests!

She also confirmed the schedule and release squad.

Schedule:

  • Beta 1: 11 February 2020 (4 weeks from kickoff)
  • Release Candidate 1: 03 March 2020 (3 weeks from beta 1)
  • General Release: 31 March 2020 (3 weeks from release candidate 1)

Squad:

Third, @francina referred the group to @jeffpaul’s 5.4 release-cycle page and then, comparing herself to a DJ at a wedding, opened the floor to other announcements.

That prompted @karmatosed to link a proposed list of design priorities for 5.4.

Answering the question from @francina, @karmatosed asked the group (plus you and me, dear reader) to comment on the post with our feedback. Priorities are open, as long as we keep in mind what we can finish by February 11 — Beta 1.

(Ed. note: If this is your first major release cycle, and as a reminder for the rest of us, new features and enhancements must be largely complete by the time we release Beta 1. We call this a feature freeze.

Further betas and the release candidates are for bug fixes and patches. There’s also a string freeze at RC1.)

Highlighted Posts

@francina turned the group’s attention to the Release Model Working Group post that sets the kickoff date for January 29.

Again, if you’ve got thoughts on how to organize the work, or things you’d like to see happen, please comment on the post.

See more of the conversation here.

@karmatosed made one final point, asking if the working group could alternate meeting times to include the whole globe, and devchat attendees readily agreed.

Components Check-in

@ianbelanger asked for help testing and submitting patches for 19 bundled-theme tickets and 39 Twenty Twenty tickets, so at lease some of them can get into 5.4.

@azaozz reported fast work on wp-lazy-loading and asked for more eyes/reviews/suggestions/testing.

https://github.com/WordPress/wp-lazy-loading

@johnbillion and @clorith reported steady progress on tooling and Site Health, respectively. @xkon reported some small fixes and enhancements in privacy. See the transcript.

@jorgefilipecosta announced the release of Gutenberg 7.3, “featuring a very significant performance enhancement.” (I think he means it’s faster. 😜)

Here’s the post:

https://make.wordpress.org/core/2020/01/22/whats-new-in-gutenberg-22-january/

He touted the navigation block as the big feature for 5.4 and pointed us all (you too, dear reader) to this board for tracking the status for that block.

Finally, @audrasjb brought up Plugins and Themes auto-updates, tickets #49199 and #48850. He pointed out we still need feedback from a variety of core committers and component maintainers if we’re going to get these into 5.4.

After a resounding chorus of emoji support for @audrasjb‘s points, @francina called Open Floor.

Nobody came forward, so devchat ended eight minutes early.

#5-4, #dev-chat, #summary

Editor chat summary: Wednesday, 22 January 2020

This post summarizes the weekly editor chat meeting on Wednesday, 22 January 2020, 14:00 WET held in Slack.

Gutenberg 7.3

@gziolo announced that the Gutenberg 7.3 release was planned to happen later in the day and said, this release includes among others:

  • Multiple performance improvements.
  • A new block collections API. The API is useful when a developer wants to group the blocks in its section in the inserter.
  • Further improvements to the Navigation block.
  • New experimental blocks for the full site editing.

More details about this release are available on the release post.

Weekly Priorities

For this week, we keep the same priorities as last week:

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

Task Coordination

@karmatosed

Has been mostly focusing on navigation block feedback/iterations and global styles – will continue to do this into next week.

@retrofox

Has been working on adding the background color feature to the navigation block, it is already merged.

Now is improving the sub-menus design, and polishing the feature.

It is possible to track the progress in the project dashboard.

@isabel_brison

Worked on resizable editor PR https://github.com/WordPress/gutenberg/pull/19082.

All the tests are now updated, and it’s ready for further review. There’s a bit of discussion on how to isolate the editor-specific styles for manipulation in the core, any feedback appreciated at this point!

@youknowriad

Has been working on the icons package. Referred Icons are all over the place in Gutenberg right now, and thinks at least we should gather them in a single package. Said technology-wise, we still need to explore different options to how best ship them for authors, but a tree-shakeable npm package seems like the best initial path forward without BC concerns. @youknowriad will continue working on a solution to this problem.

@youknowriad is also working on an Extensibility API Proposal ( will share more very soon) and keeps doing heavy triage as time allows.

@andraganescu

Is working on an attempt to have responsive backgrounds in blocks which have image backgrounds, and doing various tidying up PRs for the navigation block.

@getdave, @marek, and @jeryj

Are working on the navigation block.

@jeryj is improving the UX.

@getdave and @marek are working on the ability to Create Pages from within the Block on the fly. Relevant issue and PR:

@nosolosw

@nosolosw is focusing back on the work on Gutenberg. Revived a lingering PR to fix a focus issue in the gallery block https://github.com/WordPress/gutenberg/pull/14930. The PR needs a technical review!

@jorgefilipecosta 

Since last week:

For the next week:

  • Help to have a “Global Styles” mechanism in the core.
  • Continue the work on Angle Picker and Gradient type picker for the custom gradients.
  • Focus on triage issues. Reviewing PR’s required for 5.4 beta 1.

@mapk 

@aduth

  • Helping around improvements and consistency among various link components
  • Hoping to try to push user-meta-based preferences persistence (sticky preferences) over the finish line. @aduth referred it would be a nice feature for WP 5.4.
  • Would like to visit some project management automation at some point.

@chopinbach

Is getting up to speed on Gutenberg development.

f you are also starting and are finding any challenge, please share it so that we can improve the experience for everyone.

@gziolo 

Open floor

Template lock active at the post type level, and templateLock={ false } in InnerBlocks causes an invalid block warning

@chrisvanpatten brought up issue https://github.com/WordPress/gutenberg/issues/11681 and asked if there are any options to move the issue forward as the issue is causing a frustrating experience. The ticket seems stalled without a clear path.

Currently, @chrisvanpatten  relies on dispatch('core/block-editor').setTemplateValidity(true); as workaround to the problem.

@youknowriad said the plan outlined in https://github.com/WordPress/gutenberg/issues/11681#issuecomment-549641097 seems a sensible one. But the ticket is stalled because implementing that solution is a big-time investment.

@chopinbach volunteered to help address this problem, and @chrisvanpatten volunteered to team up. Thank you both!

FormTokenField: Make it possible to add children

@scruffian asked for feedback on https://github.com/WordPress/gutenberg/pull/19676.

@youknowriad said that while the change is minimal, it would be good to expand on the use-cases. @youknowriad referred that adding random children may not be the best path forward, and asked if there is another abstraction possible, or if the button is something that can be built-in.

@scruffian said @youknowriad ideas are valid, but his thought was that it would be more useful as it was proposed in the PR. @scruffian  is open to achieving the result differently.

Server-side context API

@chopinbach asked for the latest updates on server-side context API @epiqueras is working on.

@epiqueras said the API is similar to React context and that he needs a PR review.

@youknowriad and @mcsf referred that ideally, a block consumes from a “contextname”, not a “blockname” and different blocks can use the same context name to expose their context.

@epiqueras linked to a comment providing some reasons where the approach may have problems.

The conversation will continue on https://github.com/WordPress/gutenberg/issues/19685. If you have any insights on this issue, please provide them as it may be valuable.

#chats, #core-editor, #editor-chat, #meeting, #meeting-notes, #summary

WP Notify Meeting Recap – January 20 2020

This is a recap of the WP Notify meeting held on Monday, January 20, 2020, 14:00 UTC. You can read the meeting discussion here.

Based on feedback received at meetings and comments, we focused on making the Objectives section in the requirements document more concise.

We also added a Use Cases section, based on feedback from the previous meeting recap post.

Use Cases

This is the excerpt of the “Use Cases” section as compiled by @folletto and @psykro.

Section 2. Use Cases
1. Action required: the plugin wants the user to take a decision, i.e. “you got a comment” (action, notification)
2. Onboarding: the plugin wants to provide guidance on a specific feature, i.e. “try this feature” (action, on-page/notification)
3. Informative: the plugin wants to inform the user about something, i.e. “backup completed” (no action, notification)
4. State: the plugin changes its state, i.e. “settings saved” (no action, on-page)
5. Marketing: the plugins wants to advertise something or suggest an upgrade, i.e. “buy an upgrade!” (action, on-page)

Requesting Feedback

  • Should we address possible unintended uses (example: Notifications of subscribe/unsubscribe from site which may include a profane username?) @folletto
  • For implementation, should we port notifications (such as marketing notes) only to the user who activated the plugin? @m1tk00
  • Further comments / remarks on the 📄 Requirement Document are welcome, and we added appendix references of related projects for inspiration (https://docs.google.com/document/d/1SoIaFqXkXiVzq5mizbZQafMfL36bD0WKj8iwYM823MI/edit#)

Next Slack Meeting

📅 Monday, January 27 @ 14:00 UTC

A note about how we hope to advance the project forward at a steady pace: by working together on the requirements document during meetings, and as time allows in between with comments and channel talks. Once we gather feedback on our goals and actionable steps in the best interest of a merge-able project, then we will progress with next sections of the document and work. @psykro @hrmervin

#feature-plugins, #feature-notifications, #summary

Dev Chat summary: January 15, 2020 (5.4 week 1)

The chat was facilitated by @francina on this agenda.

Full meeting transcript on Slack

Announcements / WordPress 5.4

At the moment there are 288 tickets milestoned for 5.4.

@francina is working on putting together a release squad. Some roles are already confirmed:

The whole team should be assembled by the end of the week. There is a fewer roles than in 5.3, because it’s a shorter release. The first Beta release is in 3 weeks from now.

@davidbaumwald expects to release the bug scrubs schedule by the end of the week.

@karmatosed added that Core design triages (on Mondays) for a few weeks can also focus on 5.4 to boost things.

@audrasjb noted that depending on the number of accessibility related tickets, the Accessibility Team can organize some extra accessibility focused bug scrubs. He will check the milestone to see if there is a need for more accessibility bug scrubs.

As @azaozz stated, hopefully component maintainers will take bigger and bigger part in “driving” 5.4, and releases in general.

@pbiron asked if there is a specific focus for 5.4. @francina answered that in general, 2020 is going to focus on one big goal: full site editing with Gutenberg. @dingo_d noted that it would need some coordination with the Theme Review Team.

@paragoninitiativeenterprises noted that #49200 needs feedback from anyone interested in WordPress security, or who develops plugins/themes.

@audrasjb is working on two tickets related to Themes and Plugins auto-updates: #49199 and #48850. This is one of the 9 projects for 2019-2020. The design team already provided some helpful feedback. These tickets are now waiting for technical review so they could hopefully land in the next couple of releases.

@marybaum noted her availability for copy review on 5.4 features.

@azaozz reported the Media team will release a feature plugin for lazy loading, so it can be tested well before adding to core. The plugin should be available in a couple of days.

@francina mentioned that development on 5.4 should have started the day 5.4 was branched, back in October. In fact, many people wait for the kickoff to start working. With Beta release scheduled in 3 weeks, it’s not really the time to add not fully ready features to the scope. However, WordPress 5.5 agenda is already known, so there is no need to rush things.

@azaozz and @francina pointed out that as soon as a release’s code is moved to a branch, trunk is back in business for the next release.

@xkon noticed that the “Current Release” widget on Make/Core might be confusing for newcomers as it’s still indicating 5.3 as the current release in progress.

Calls from component maintainers

Media: @azaozz is looking at couple of small enhancements for the uploader changes from 5.3, specifically adding a link in the UI to the original image (if it was scaled), and looking at some of the edge cases when creating image sub-sizes, file size for large PNGs, etc.

Widgets & Menus: @audrasjb will coordinate with @welcher to identify priorities for an eventual specific bug scrub.

Build tools: @johnbillion is going to look at getting several of the Composer related tickets into 5.4 (like using Composer for external libraries and phpunit). @desrosj and @johnbillion to synchronize their work at some point as @desrosj is working on backporting the local Docker environment.

Comments: @imath committed to look at each ticket involving comments in 5.4.

Open Floor

Some new contributors asked about how to start with core contribution. Worth noting the next New Contributor Meeting is scheduled for next Wednesday at 20:00 UTC in #core Slack channel. This is a great opportunity to ask for help or to learn how to contribute to WordPress Core.

@francina noted that @chanthaboune and @andreamiddleton are both nominated for CMX Awards. Everybody can vote for them on the dedicated website.

#5-4, #devchat, #summary

WP Notify Meeting Recap – January 13 2020

This is a recap of the WP Notify meeting held on Monday, January 13, 2020, 14:00 UTC. You can read the meeting discussion here.

We’re resuming our work on the WP Notify project with better focus on actionable ways to address the challenge of notifications in WordPress.

We started by answering more pointed questions as to what the solution must address, and whether a temporary alternative should be entertained at all.

Temporary Solution

@psykro suggested to post a separate trac ticket, to improve the current admin_notices implementation, with sample code from @apedog

The benefit to this is that, as a team, we get something into core that improves users lives and we gain some real world experience of how the process could be improved by the final solution.

The negative is that it would mean this code is likely to be eventually replaced by our final, better solution. This very discussion, is the reason we want to present this concept to the community, for feedback on whether to a) expand admin_notices, or b) affirm the need for an entirely new replacement solution altogether, and what are the critical elements of that new approach

@schlessera is of the opinion, and rightly so, that any work done to improve the current admin_notices functionality is not worth the time. We should rather work on a solid, scalable and manageable solution for notification channels.

Permanent Solution (From The Onset)

A few of the very direct questions we must address for the replacement solution as suggested by @folleto are

  • What are we replacing? (if anything)
  • What kind of backward compatibility do we need?
  • What’s the minimal API and UI we need to build for a v1?

As we answer these questions, we’re keeping in mind the end-user experience together with the API required. For example, a notifications menu will need a completely new way of handling notifications in WordPress API through use of the database and rendering those messages.

As @schlessera pointed out “The initial UI should satisfy the 80% need of letting Core/plugins/themes communicate platform state changes within the admin dashboard in a scalable way where the user/user group keeps control.”

Meeting time

During the course of the meeting it became somewhat clear that the time of the meeting might be causing some problems for folks in different time zones. Conversation in the meeting became much more active after the first hour. Therefore we would like to know if the current meeting time is suitable, or if we should consider an alternative?

Next-Steps

Please comment with your thoughts below. You can also add comments your comments in the WP Notifications Project Google Doc under Section 1. “Objectives”

Next Slack Meeting

📅 Monday, January 20 @ 14:00 UTC

#feature-plugins, #feature-notifications, #summary

Media Meeting Recap – January 9, 2020

Here’s a summary of the #core-media chat from January 9, 2020. Weekly media meetings happen on Thursdays at 14:00 UTC; see the full transcript here, in the Make WordPress Slack.

Attendees: @joemcgill, @karmatosed, @antpb

Upcoming Meeting Schedule

Happy 2020! Because of the holidays, the group postponed chats until Thursday, January 9.

This morning, the group also discussed moving the regular time, so more people can join the chat – particularly people working on critical tickets in the 5.4 release cycle.

Here are three options. Vote for your favorite in the comments:

  • Move the current Thursday 14:00 UTC time to 15:00 UTC
  • Move the date to Tuesday at 21:00 UTC (this option works well for the three who came to today’s meeting.)
  • Multiple meetings, to account for both sides of the world. This option would likely require a push of the currently scheduled meeting to 15:00 or 16:00 UTC as well as an agreed time and date for the second meeting. @joemcgill suggested that multiple meetings not be forced to cover the same agenda items. Some items will overlap where it makes sense, but, for example, if one meeting has cleared the ticket queue, it would be pointless for the next meeting to consist largely of a triage.

New Media ticket triage

#48194 – Unregistered image sizes used for IMG tag “srcset”

As @joemcgill pointed out: “The problem here seems to be that someone has deleted image files that are still referenced in the database in attachment metadata. Regenerating image sizes ( wp media regenerate ) would fix this problem, but should we only use registered sizes in `srcset` attributes if there are other sizes available?”

#48321 – Hotswapping featured image with gallery images

It seems the ask is for (after creating gallery) the option to click on one of the gallery items and set as featured image of the associated post. It was agreed by attendees that this may not be best fit in the gallery block UI and perhaps would be better fit as an option within the media modal when creating galleries, images, etc.

The group changed the ticket to ask for reporter feedback.

@karmatosed made another point. The “Uploaded to this post” filter, in the Set Featured Image modal, does give the reporter part of what they’re asking for.

#48325 – Additional filter in media-template.php. Let developers hide attachment page link.

@joemcgill pointed us to the code that creates the attachment link: https://github.com/WordPress/WordPress/blob/master/wp-includes/media-template.php#L511 and said, “At minimum, I think that template should check that data.link is actually a URL before displaying [it]. [Developers] could filter the data that is used by this template.”

WordPress 5.4 Media Focuses

While it didn’t come up in the meeting, notes are a great place for all of us to develop ideas for Media focuses in 5.4.

If you have any media-related focuses you’d like to work on in the 5.4 cycle, and that you’re ready to work on, please leave a comment.

That helps the Media maintainers gather and prioritize the work. Plus, it would be great if you’d come to next week’s chat so we can all discuss your idea!

#core, #core-accessibility, #core-media, #media, #summary

Media Meeting Recap – December 19, 2019

The following is a summary of the weekly media component meeting that occurred on Thursday, December 19, 2019. Weekly media meetings are held every Thursday at 14:00 UTC. A full transcript can be found here in the #core-media room in the Make WordPress Slack.

Attendees: @joemcgill, @mikeschroder, @antpb, @flixos90, @karmatosed

Upcoming Meeting Schedule

Due to the holidays, we are postponing weekly meetings until Thursday, January 9.

Additionally, we are planning to adjust the meeting time in the new year to allow for better attendance from people working on priority tickets during the 5.4 cycle. @joemcgill will be reaching out to component maintainers to gather preferred times and will post an updated schedule before January 9.

WordPress 5.4 Media Focuses

As planning for WordPress version 5.4 is beginning, @francina has reached out to component maintainers to see if there are any major plans for this release. Here are the items currently being discussed:

  • #44427: Introduce lazy-loading API for media and other elements@flixos90 is leading this effort and will be looking for feedback.
  • @azaozz plans on working on more meaningful error messages when uploads fail (possibly in cooperation with Site Health).
  • @azaozz also plans to look into deprecating some of the “notoriously misused” image related functions, like constrain_size_for_editor().
  • Several other regular contributors are still working out how much time they’ll have to contribute in the new year and what their focuses will be.

If anyone has any additional media-related focuses they plan to work on during the 5.4 cycle, please leave a comment below so we can gather and prioritize work in the new year.

Hope to see you all in 2020 🎊

#core, #core-accessibility, #core-media, #media, #summary

Dev Chat summary: December 18, 2019

Please note Dev Chat is suspended on December 24th and January 1st 2020. It will be back on January 8th 2020, same time, same place!

The chat was facilitated by @francina on this agenda.

All the discussions can be found in Core channel on Slack here.

Announcements and highlighted posts

@audrasjb gave an update about 5.3.1 version that was released on December 13. Right after, a couple of high severity issues were raised on Core Trac. The release team then planned and held two bug scrubs and released a provisional schedule for 5.3.2.

The first Release Candidate for 5.3.2 was released on December 17, with the 5 main issues fixed.

Update: WordPress 5.3.2 went live later yesterday after the devchat.

@francina gave a quick update of WordPress 5.4, which is ETA is still March 31 as initially planned. She is currently collecting feedback from component maintainers and the release could eventually be shortened if there are no big features planned to ship into the version.

Components Check-in

@johnbillion precised that component maintainership doesn’t mean having to fix all the bugs, and that it’s more a shepherding role. So, anyone interested in maintaining a component or just wanting to know more is welcome to ping a committer or release lead.

@imath called for attention on #33717 from the Comments component to which he proposed a patch.

@francina then manifested her desire to see the Comments components as one of the focus for 5.4, since it has been abandoned for a while.

An interesting discussion about components and components maintainers then took place. @francina asked about how the Core team can help with the recruitment of maintainers.

@karmatosed suggested a few steps that would basically consist in

  • Clarifying what component maintainers do.
  • Being ok with people going in and out of that role, almost encouraging it to spread good people around.
  • Looking at what is a focus for this coming year.

@garrett-eclipse suggested we do on Make/Core on seeking maintainers. He also proposed we can see who the regular contributors are in the component and reach out to them specifically.

@mikerbg said that a good step would be to identify individuals that are willing and able to provide some assistance to the marketing team to publicize recruitment opportunities and needs.

@jeremyfelt reminded this discussion from a chat in May, that it might worth looking at.

The full transcript of the discussions about components and components maintainers can be found here.

#devchat, #summary

Devchat summary: December 04, 2019

@francina led the chat based on this agenda.

Announcements

@audrasjb gave an update of bug scrubs for 5.3.1 minor release. The current status is 3 scrubs already done and 3 others scheduled for the rest of the week. The agenda of the scrubs for the release is available here. There are currently 20 tickets closed as fixed and 29 open for the milestone. Audras Jb also confirmed that targeted date for the release is December 11 or 12.

There was also a small discussion with @audrasjb, @marybaum, @azaozz and @johnbillion about the correct appellation of the testing phase before the minor release, either Beta of Release Candidate.

@azaozz also stated that a good date for the first Release Candidate can be early in the week of Monday 9, and that the team can organize another scrubs if any new bugs appear.

@francina gathered opinions about the release team. The team for WordPress 5.3.1 release is officially constituted by @sergey, @audrasjb, @amy kamala, @marybaum, and @whyisjake.

@francina reminded about 5.4 release which is still  in early stages, and shared the link of its open call for tickets. Everyone interested is invited to add their comments.

Highlighted Blog Posts

@francina shared this post about WordPress 5.3 retrospective recap and next steps.

Open Floor

Another discussion about a possible date for 5.4 and releases cycles duration happened. @francina reminded that the targeted date for now is March 31st 2020, after @jorbin asked if it can take place in January.

Francina also precised that there is currently an ongoing discussion about shortening the futures releases cycles.

@azaozz stated that “historically” the holiday season has been slow on the “development” side and quite lively on “organizational” side, and that this can be a good time to speed things up.

@jorbin stated that the short cycle for 5.1 last year showed that we can get a beta out in January and release in February without much difficulty.  @francina then point us to this Matt’s message, where he mentioned that the team is trying to get as much as possible into point releases, including possibly Gutenberg updates; point releases being only about regressions.

@jorbin reminded that during the 4.9 release cycle, the decision was made to start backporting some features. And that he thinks that this is only needed if we keep the slow major releases that we have had historically.

@francina then proposed a working group that will evaluate how we can reduce the manual work for the futures releases. And asked if there are already tools or procedures for that.

@johnbillion precised that his tought  is that a release schedule makes releases and makes time planning easier for everyone.

Important reminder from @nacin about the biggest focus area if the team want to speed up things should be automated testing and updates process.

The devchat hour ended up with @francina allowing attendees to continue the discussion for an extra time as it might be a kind of blocker now.

The rest of the discussion about releases cycles can be found starting by here in #core.

Details about others aspects of this have been discussed in the following posts:

#devchat, #summary

WordPress 5.3 Retrospective Recap and Next Steps

The week of WP 5.3 release I posted a call for feedback for the development workflow.

Thank you to everyone that left their comments! Reflecting on what worked and what didn’t is a great way to move forward together and steer the wheel if and when needed.

Some comments didn’t follow the proposed format of start/stop/continue so it wasn’t very clear where they fit: I tried to put them in one of the categories. I also rephrased some feedback that was sometimes given as a positive statement (continue doing A instead of B) and sometimes a negative statement (stop doing B and do A). Finally, I added feedback I collected from the focus leads or from anonymous sources.

If something doesn’t feel right let me know and I will amend the post.

Read on for everyone’s feedback!

Continue reading

#5-3, #summary