Tentative Release Calendar 2020-2021

During the 5.3 release cycle I heard that the uncertainty of next release date was a concern for many.

I am happy to introduce you to a tentative release calendar for the next two years. But first…

Tentative why?

  • Because the exact dates will be confirmed only when the release cycle kicks off to be sure that there is enough time to work on the issues and features that are planned
  • Because I don’t know if there is going to be a major change or shift in technology, especially from third parties, so being cautious is natural.
  • Because there is also another sentiment going around the WordPress community, that the project can handle more frequent releases, so there might be some changes in the way things are done.

From 5.4 to 6.0

Major Version Potential Release Date
5.4 2020/03/31
5.5 2020/08/11
5.6 2020/12/08
5.7 2021/03/09
5.8 2021/06/08
5.9 2021/09/14
6.0 2021/12/07

Major religious holidays for multiple faiths and Federal US holidays were taken into consideration. If you spot a date that is a big no, please comment below before December 4th.

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

Dev Chat Summary: November 20, 2019

Here’s a summary of the November 20 Dev Chat (agenda / Slack archive).

Announcements

The 5.3 Retrospective – Call for Feedback post.

@clorith asked, “Would it be an idea to also allow for an anonymous form to submit to that? I know some folks may not be comfortable with the potential for conflict, and may feel safer giving an honest feedback if it wasn’t all public under their name? Then the feedback could be provided by the leads under a followup post, with no relation to individuals.”

@francina said she’d change the post to mention that anyone who’d like to give feedback privately is welcome to do so. 5.3 release leads @davidbaumwald, @youknowriad, @justinahinon, @audrasjb also committed to offering the same.

Upcoming Releases

5.3.1

@whyisjake offered the current list of tickets in the milestone at https://core.trac.wordpress.org/query?group=status&milestone=5.3.1

After a quick discussion of potential release dates, December 11, 2019 came out a potential winner. It’s pretty soon, but it still gives us time to triage 5.3 regressions and bugfixes. That decision is not final – it’s pending more discussion in the comments.

Got thoughts on timing? Please leave them in the comments – the sooner the better.

While we see how those conversations shake out, @audrasjb graciously offered to lead the first 5.3.1 bug scrub on Thursday November 21, 2019 18:00 UTC

Next up: a call for volunteers to lead the release.

@sergeybiryukov, @audrasjb, @amykamala, @marybaum, and @whyisjake all raised their hands. Everyone expressed great confidence in the potential candidates.

Want to be part of the 5.3.1 release squad? Please leave a comment.

Open floor

@youknowriad brought up a discrepancy in the release cadence between WordPress Core and Gutenberg:

By December 11, the date proposed for a 5.3.12 release, Gutenberg will be ahead of Core with about 5 releases and this is a problem. 12 Gutenberg releases shipped into 5.3 . This is too much for a single WordPress release and with the current schedule, it’s seems like this is going to be similar for 5.4. This is not tenable for the future. It’s hard to stabilize and ship, it’s hard to summarize the changes for third-party [developers] and users, it’s more scary to ship and people were recommending the plugin to be installed for their clients (and it’s risky since the plugin is a development plugin). So how to reduce that gap is a big issue that needs solving IMO.Ideally I do think a shorter release cycle for majors is better. (Why not just a 5.4 in like end of January). [O]therwise we’ll have to include enhancements in minors.

This generated a long discussion that continued well past the end of the Dev Chat. See the full conversation starting here.

@davidbaumwald led the chat and wrote these notes. @marybaum did some editing.

#5-3, #devchat, #summary

Dev Chat Agenda for November 20, 2019

Here is the agenda for the weekly meeting happening later today: Wednesday, November 20, 2019, 09:00 PM UTC.

Agenda

  • Announcements
    • Highlighted posts
  • Upcoming releases
  • Calls from component maintainers
  • Open Floor

If you have anything to propose for the agenda or specific items related to those listed above, please leave a comment below.

This meeting is held in the #core channel. To join the meeting, you’ll need an account on the Making WordPress Slack.

#agenda, #core, #devchat

Editor Chat Agenda: November 20

Note taker: @nosolosw

This is the agenda for the weekly editor chat scheduled for Wednesday, November 20, 2019, 14:00 UTC.

Please, note that the chat time has been updated to 14 UTC.

This meeting is held in the #core-editor channel in the Making WordPress Slack.

  • Weekly Priorities
  • Triage role for GitHub.
  • Task Coordination
  • Open Floor

If you have anything to share for the Task Coordination section, please leave it as a comment on this post.

If you have anything to propose for the agenda or other specific items related to those listed above, please leave a comment below.

#agenda#core-editor#editor-chat

REST API Chat Summary: November 14

This post summarizes the weekly REST API chat meeting for November 7, 2019. (Slack transcriptAgenda). Weekly REST API component office hours are held every Thursday at 18:00 UTC in the #core-restapi room in the Make WordPress Slack.

Authentication

A new wp-api/authentication GitHub repository was created last week to facilitate the design & development of a REST API authentication solution for WordPress Core.

We continue to be in the information gathering stage. For all interested in contributing to this effort, we will be using part of our weekly REST API office hours each Thursday at 18:00 UTC (Thursday, November 14, 2019, 01:00 PM EST) as a weekly standup to coordinate work.

We also invite you to log issues describing use cases the authentication solution should support.

Registered Block Types REST API

#47620 aims to create REST API routes to discover the list of registered block types. It is based off the Gutenberg Block Type Registration RFC. @spacedmonkey worked on a patch and is in the process of soliciting feedback from the Gutenberg team, Mobile team, and other members of the REST API team.

A particular point of concern @spacedmonkey brought up was the difficulties about handling the asset fields ( editorScript, script, editorStyle and style ). The RFC defines the fields as either absolute URLs or relative paths to the source files. However the WP_Block_Type class defines those fields as asset handles.

Further the asset URL or handle is not sufficient to make the asset functional. The list of dependencies, inline scripts, translations, and localized data are all necessary for the script to work.

@timothyblynjacobs mentioned that the RFC discusses statically discovering that information from an associated .asset.json file located “next” to the script file. @aduth mentioned that section is slightly out of date since @wordpress/scripts now outputs a .php file instead of a JSON file.

The participants discussed whether it would be better to include this additional information inline in the Block Type response, or to develop a separate wp/v2/dependencies API.

@timothyblynjacobs suggested that including this information inline would be simpler. @spacedmonkey pointed out that then we’d be including full data from a separate resource within the block type response. Elsewhere in the REST API that would be handled by creating a separate API and linking to it.

Additionally, @timothyblynjacobs pointed out that just exposing the list of dependencies isn’t sufficient. The client needs access to the entire dependency graph to ensure each dependency’s dependencies are loaded, and that all scripts are loaded in the correct order.

This all points to a dedicated REST API endpoint being a better solution. The team then discussed the potential privacy and security ramifications about retrieving this information about any registered asset.

A developer may include sensitive data in a wp_localize_script or wp_add_inline_script after registering the script with wp_register_script. Currently, this data would only be exposed when the script is enqueued, which may be protected by a current_user_can or $hook-suffix check. If the REST API allowed returning information about an arbitrary asset handle, this data may be exposed.

Additionally, a developer may conditionally registers asset based on a plugin’s settings. By allowing a user to check if a handle is registered via the REST API, it may be possible to determine the setting configuration of a plugin. This may not be desirable for security or privacy related plugins.

@kadamwhite mentioned that historically the REST API has been pretty conservative about what data is exposed. If possible, he’d like to continue along that path. Or theoretically authentication could be required for some pieces of the API since the use case seems to mostly be for editorial interfaces which would require auth anyway. @spacedmonkey also suggested a capability check.

@spacedmonkey and @timothyblynjacobs proposed limiting the assets exposed to ones registered via WP_Block_Type and all WordPress Core assets. Additional assets could be exposed via a registration flag of some kind, like show_in_rest.

Both @aduth and @youknowriad mentioned that this functionality would not just be useful for blocks. As WordPress moves more and more to JS powered interfaces, the ability to lazy load assets will become increasingly important. The problem here could be generalized to “retrieve all the information necessary to properly load a handle”.

@youknowriad opened a ticket, #48654, to continue the discussion on Trac.

Agenda for November 21

The next REST API meeting is happening in #core-restapi at Thursday, November 21 at 18:00 UTC. Agenda:

  • REST API Authentication project weekly meeting
  • Menus API discussion
  • WP Dependencies API
  • Review open tickets which should be provisionally milestoned for 5.4
  • Open floor

#meeting-notes, #rest-api

5.3 Retrospective – Call for feedback

5.3 “Kirk” was released on November 12, 2019. It was twelve weeks in the making, it had a big team behind it and the highest number of contributors ever. Congratulations to everyone!

In order to prepare a retrospective post, I would like to ask everyone to leave some comments below with things they would like to bring up. To help, here are some questions to ask yourself:

  • What should WordPress start doing as a part of the development process?
  • What should WordPress stop doing as a part of the development process?
  • What should WordPress continue doing as a part of the development process?

Please share your thoughts in the comments below! Remember when commenting to keep the discussion professional and focused on ways the process of creating WordPress is either already working great or can be improved.

Edited to Add: if you rather not give your feedback in a public space, please reach out to the following people on Slack. They are available to collect your feedback in a safe space, with no judgement and use it in the retrospective in an anonymous form:

#5-3, #retrospective

Dev Chat Summary: November 13, 2019

@francina led this week’s dev chat – the last one of the 5.3 release cycle – see the agenda here.

For the full transcript, see the Slack archive here.

Your faithful reporter: @amykamala. Let’s get going!

Announcements

@francina opened Announcements with the release of WordPress 5.3, which went live on November 12, 2019!

She congratulated everyone, NOT just the folks active in the chat, on an amazing job. Several Core committers were especially pleased that 5.3 came in on schedule (🎉) with the biggest group of contributors ever.

Here are a few statistics:

  • 12 weeks of development
  • A release squad with nine focus leads, covering every relevant component that got an update
  • 645 contributors
  • 658 bugfixes
  • A new default theme, Twenty Twenty
  • Lots of fun and new friends made
  • And much, much more!

Before release the squad counted at least 153 user-experience enhancements.

Highlighted Posts

The annual WordPress survey is open! Your feedback is not just appreciated – it’s vital to the future of WordPress. So please fill it out and share it everywhere you can think of.

Tanking the floor for a moment, @chanthaboune told the group this survey is new – not the same as last year – and is broader. Whether you’re a contributor, designers, developers, users or hosts, please participate!

Again, please share the survey with anyone who touches WordPress in any way.

5.3 Housekeeping

Big thanks to everyone who has helped with testing so far! If that includes you, please keep testing and report any issues, concerns or enhancement ideas in a comment on Trac.

That’s how WordPress gets better and you get to shepherd your best ideas through the process.

Need a refresher on how it works? Here’s an outline of the post-release process.

@francina wrapped the discussion with a note that in the next few weeks the release leads will open a call for retrospective. Want to share some honest, constructive feedback? That’ll be your chance!

5.3 Housekeeping Calls from component maintainers

@francina opened the floor for component maintainers to bring up topics for discussion. These are the components.

@marybaum said “I love that we have a #core-css channel. Does that mean Core CSS is a component?”

@peterwilsoncc replied, “it’s closer to a focus than a component. Tickets can still be assigned to the affected component, eg Admin, Themes, etc. “

@sergey asked “If we have a `javascript` focus, should we add one for CSS as well? 

After a few more comments from folks, @francina reminded all 30,000-plus potential attendees that we don’t make final decisions in devchat.

She asked the folks talking about CSS to follow this process:

  • Make a proposal on the Core blog
  • Discuss
  • Come to a conclusion
  • Act

Here are the reports from other component maintainers:

@williampatton: “Themes component is looking good. Prepping for next release.” 

@peterwilsoncc: “From the security team, now we have a Travis CI account that allows for private repos, we have the security tests running regularly. It should make it easier to find out if they’re passing during the release process.” and went on to ask @sergey if it was possible to add it to Trac.

@garret-eclipse: “In the privacy component @rogierlankhorst has started work on a consent api.

Open Floor

@mensmaximus asked whether “we ever change the user management screen to a tabbed interface. What is the current state and what do core devs think?”

@williampatton started with a general reply: “There are lots of thoughts on redesign for user management, but lots of ideas mean lots of decisions [making it] hard to reach agreement.”

A lively discussion followed. Hopefully the WordPress world will see some new ideas for an even more usable Admin experience!

(Ed. note: The UX discussion and the conversation below, about jQuery, happened at the same time, and you’ll see the comments jump from one to the other. Still, imo, both are worth your time and effort to decipher!)

@enrico.sorcinelli has “noticed that Juery’s `$` is no longer globally defined in admin.” That’s made some of their client sites cause issues with users’ code.

@clorith answered, “The jQuery `$` being globally available was a bug.” That bug got fixed in one of the JS updates in 5.3.

“Although it’s not ideal, reports of issues are fewer than expected, and the code errors would be within the plugin code,” @clorith continued, adding, “I tend to lean towards leaving it being the right thing.” 

Here’s the ticket they’re talking about and the full discussion, including some observations on the future of jQuery.

@clorith noticed two items leading the pack of recurring issues, 24 hours in:

  • The update to add_submenu_page gives doing-it-wrong errors. We knew this, but devs weren’t prepared for users to have debugging enabled. 
  • The change to spread operators had plugins breaking, because things like custom walkers had dependencies on the previous operators.

See the full discussion starting at the link above. (Ed. note: this highlighted test is the same link.)

@pbiron asked if anyone had reported problems with the new big-images or rotate-on-upload features. 

@clorith and others noted very few issues.


#5-3, #devchat, #meeting-notes

REST API Chat Summary: November 7

This post summarizes the weekly REST API chat meeting for November 7, 2019. (Slack transcript, Agenda). Please note that this meeting did not change time for daylight savings, and Weekly REST API component office hours continue to be held every Thursday at 18:00 UTC in the #core-restapi room in the Make WordPress Slack. 🙂

Authentication

The first half of the meeting discussed the newly-created wp-api/authentication GitHub repository, a follow-up to discussions at WCUS contributor day around rebooting work towards a canonical, core Authentication solution to permit the Mobile team to use the REST API instead of XMLRPC.

Our target for a merge proposal some time next year is to have an use the OAuth 2 handshake flow with dynamic client registration, which issues revocable, long-lived JWT tokens. The repo has no content so far, but we will start work by focusing on UX and the desired user-facing and technical flow rather than diving immediately into code.

@spacedmonkey, @derekherman, and others intend to drive this project over the coming months. If you who is reading this or any colleagues of yours are interested in contributing to this effort, we will be using part of our weekly REST API office hours each Thursday at 18:00 UTC (Thursday at 18:00 UTC) as a weekly standup to coordinate work.

Priorities & Goals

Priorities for Next Release

Key tickets highlighted for consideration as part of the next release cycle include, but are not limited to,

  • Improve performance in route matching #48530
  • Support registered default meta values #43941
  • Permit schema filtering #47779

If you have a ticket to highlight or propose for the next bugfix or major release, please leave it as a comment below or raise it in #core-restapi. Thank you once more, as well, to everybody who helped drive our API improvements in 5.3!

Documentation

We are behind schedule in updating the REST API handbook to cover the recent changes in WordPress 5.3. @timothyblynjacobs and @kadamwhite will be working to roll these updates out over the coming week. Handbook content is managed at github.com/wp-api/docs.

Open Floor

@timothyblynjacobs raised #44568 and #44886. Because WordPress operations are non-atomic, these race condition issues are not limited to the REST API and were determined to be out-of-scope, so #44886 was closed as wontfix.

Several bugs were raised and have been provisionally milestoned for 5.4, with the option to backport as needed once addressed.

To increase contributor awareness of REST API tickets, we discussed holding periodic component scrub meetings in the main #core channel.

Agenda for November 14

The next REST API meeting is happening shortly in #core-restapi at Thursday, November 14, 18:00 UTC. Agenda:

  • REST API Authentication project weekly meeting
  • Review open tickets which should be provisionally milestoned for 5.4
  • Open floor

#meeting-notes, #rest-api