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

Editor chat summary: Wednesday, 27 November 2019

This post summarizes the weekly editor chat meeting on Wednesday, 27 November 2019, 14:00 WET held in Slack.

Gutenberg 7.0

Gutenberg 7.0 was released. It brings the navigation block out of the experimental state. The release was possible thanks to the efforts of 51 contributors. More details about this release can be checked on the release post.

Weekly Priorities

November priorities post: https://make.wordpress.org/core/2019/10/29/whats-next-in-gutenberg-november/

The priorities should remain pretty stable I think: Block Content Areas, Nesting Selection Tool, Navigation block will continue to be improved based on feedback. Gradients are almost “finished” and we may start thinking about improvements to the block interface based on this great issue https://github.com/WordPress/gutenberg/issues/18667.

@youknowriad

Task Coordination

@youknowriad

Worked on PR’s Edit/Navigation ToolFixed Toolbar on mobile, and Add a header menu to switch between edit and select tool. Hopes to continue a trend of 50% reviews and triage and 50% code.

@jorgefilipecosta

Gave support on the forums, triaged issues, rebased and updated some PR’s, submitted and merged several bug fixes, and worked on a PR that may increase the performance of the editor by caching styles https://github.com/WordPress/gutenberg/pull/18763.

On the next week: 

  • Plans to review and help some media-related PR’s, namely the refactor to the gallery, to increase reusability with the native mobile APP. 
  • Wants to finish the remove editor module usages in block-editor by applying changes to the reusable blocks and rich-text. 
  • Update the release tool to move readme and changelog files to the Github repository.

@noisysocks

Finished the work on adding a welcome guide modal, which is now ready for review.

Intends to spend the rest of this week playing with wordpress/env, seeing if we can deprecate local-env, and writing docs for this all.

@retrofox

Helped to finish the first approach of the Navigation block. Emphasize this comment: Navigation block will continue to be improved based on feedback.

@karmatosed

Contributed to the following tasks:

Is looking at iterations for navigation, going through design feedback in Tightening Up board, and seeing what needs work or is blocked, and is working on docs for the triage team.

@mapk 

 Worked on some reviews and triage, namely the NUX modal PR for @noisysocks.

@paaljoachim

Looked closer at this issue https://github.com/WordPress/gutenberg/issues/17640#issuecomment-556866662. Might need to create a new issue to bring a better focus on what he brought up.

@gziolo

Attended WordCamp Łódź, helped people on forums, worked on some triage based on reports from people. This week will resume the work on Block Patterns API.

@bph

Working on End User Documentation and connected with @melchoyce on her project to replacing gifs with videos.

Open floor

@scruffian brought the topic of how we handle Full Site Editing blocks for non-admin users.

@youknowriad referred the precedent we have in media blocks to allow/disallow features based on user capabilities, and @noisysocks referred the API we have to query user permissions.

@scruffian shared some questions he had on his mind:

  • Is the API change I suggested in https://github.com/WordPress/wordpress-develop/pull/120 sensible? 
  • I see a change in the block itself in the PR not the API and it seems reasonable.
  • How does the design of the block change when a non-admin see it – does it need a special treatment?
  • This is probably a per-block problem as you might have access to some features in the block but not everything (think alignment of a site title block)

For the API change question, @youknowriad answered, he sees a change in the block itself in the PR, not the API, and that the change seems reasonable. For the block design question, @youknowriad answered that this is probably a per-block problem as one might have access to some features in the block but not everything.

@mrMark asked the use case Navigation Block and if it is intended to replace the menu system eventually. @youknowriad said that replacing the menu system may be a possibility but not until we allow editing the full templates in Gutenberg.

As a follow-up question @mrMark asked:

As the Block Editor encroaches onto the realm of what themes would normally handle, ie presentation layer, what’s the plan for integration between the Block editor and themes?

And then @mrMark referred that the Next Generation of Themes and how they integrate with the Block Editor should start being conceptualized.

@youknowriad referred that this is a big topic and ongoing work that can be followed on https://github.com/WordPress/gutenberg/labels/%5BFeature%5D%20Full%20Site%20Editing. @youknowriad is also happy to answer any specific questions, and this topic will be part of the next week’s meeting. So in case, this is something that interests you, please join us and share your insights!

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

Media Meeting Recap – November 14, 2019

The following is a summary of the weekly media component meeting that occurred on Thursday, November 14, 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: @sergeybiryukov , @pbiron, @spacedmonkey, @afercia, @dinhtungdu, @azaozz

Post 5.3 Triage

There were a few issues that came to light after folks updated to the 5.3 release.

Issues discussed:

  • #48632 : Cannot upload images directly from blogpost – Meeting participants attempted to replicate but were unable. Related issues were #48620 and #48604 in which one of the issues were due to a plugin.

That’s all that was reported as of meeting time last week! Thank you to everyone that contributed to WordPress 5.3! It really is a great update.

Meeting Scheduling Discussion

As you may have noticed, the time for the meeting was adjusted for Daylight Savings Time and moved later by one hour. There was some discussion in the meeting around adding a second meeting to the week allowing folks from both sides of the planet to participate. If you are in the AMEA region, please leave your thoughts on when the day and time of the week that works best. This topic will be revisited in the next meeting on Thursday, November 21, at 14:00 UTC

It was also mentioned that in this new scheduling model, it would be desired to move the currently scheduled meeting later one hour. This is of course only if there is another AMEA friendly meeting scheduled.

New Issues Triage

The meeting transitioned to a bug scrub after discussion about scheduling.

  • #48562 : Audio keeps playing on closing of media/attachment details popup in WP Admin – This was reproducible via the Media Library page in grid view. This issue has been around since 5.2 also so this is not a regression. Work is happening in the ticket to fix it up. The remainder of the meeting was filled with bunnies and discussion around a fix for the issue.

Feedback

If you have any feedback on the above, please feel free to leave a comment, join in #core-media for a chat, or attend the next meeting on November 21, 2019 at 14:00UTC!

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

Core Editor Summary for November 20

This post summarises the weekly editor chat meeting (agenda), held on Wednesday, November 20, 2019, 14:00 UTC in core-editor Slack channel.

Weekly Priorities

Slack transcript.

See November Priorities post. Good to focus on these things as the month wraps to an end and start thinking on next steps.

  • Block Content Areas: expected to still be a focus for a while.
  • Navigation block (board): is close to get out of the experimental phase into the plugin.
  • Tightening up (board):
    • Polish to blocks and different parts of the UI is continuing.
    • Gradients are coming along nicely.
    • Some progress is being made to the Block Selection Tools.
    • Add color to specific text inside RichText (16014) is blocked by 17617 It’d be good to unblock those.

Triage role for GitHub

Slack Transcript.

GitHub has recently created a few new roles with more fine-grained permissions. One of those is the Triage Role that enables people to manage issues and pull request, and well as other actions. There was a consensus that this new role could help onboard new contributors and less technical folks who are not part of the Gutenberg group already.

Tasks:

If you’re interested in joining the Triage group, please, leave a comment in the agenda or the GitHub issue.

Task Coordination

Slack Transcript.

If you’re reading this asynchronously, please, add your notes as comments.

Open Floor

Slack Transcript.

Welcome feedback on this exploration of hover/selection states for Full Site Editing concepts by @shaunandrews

Request For Comments experiment. A few months ago Gutenberg started doing a RFC for major features following this post. @youknowriad noted that it didn’t get as much traction as expected. Many agreed. To close this experiment and the open RFCs is being considered.

If you have any feedback about the RFC experiment, please, comment on this post or reach out to people involved. Feedback channels will be opened until next week when a decission will be made.

#core-editor, #editor-chat, #summary