Gary Pendergast 4:54 am on March 23, 2019
Tags:   

WordPress 5.2 Beta 1 Status Update (take two)

The remaining feature tickets in the milestone have been successfully committed! Thank you everyone for helping us get there. 🙂

During preliminary testing prior to the release, however, several folks discovered an issue with the new package signing feature, which would cause subsequent WordPress updates to fail (#46615).

Out of an abundance of caution, I’ve cancelled the WordPress 5.2 Beta 1 release that was scheduled for today, and tentatively rescheduled it for March 27, 2019, pending investigation of this package signing issue. I haven’t changed any other milestone dates, though they should be reviewed once we’ve released WordPress 5.2 Beta 1, to ensure they’re still realistic.

If you’re running the WordPress 5.2 Alpha nightly builds, you may not be able to update to subsequent nightly builds from the Dashboard due to this issue. Once #46615 is fixed, you can resume updates by manually copying the new files to your test site, or by updating with WP-CLI: wp core update --version=trunk.

#5-2

Heather Burns 5:19 pm on March 22, 2019
Tags: ,   

#Core-privacy March update

This is a cumulative update for #core-privacy office hours and bug scrubs held in March 2019.

Office hours are held every Wednesday at 19:00 UTC in the #core-privacy channel on Making WordPress Slack. Bug scrubs are Mondays at 1600 UTC.

We have welcomed several new members into our channel, and were also delighted to welcome back @xkon and @javorszky 🙂

Ticket and bug scrub update

The team has shipped all of its enhancements for the 5.2 release: #44005, #44044, #44707, #44761, #44822, #44833, #44901, #45136, #45999, #46041, #46254, #46369, #43438, #44233, and #44876.

Props @desrosj, @birgire, @garrett-eclipse, @tz-media, @xkon, @cc0a, @itowhid06, @mmuhsin, @arena, @duckdagobert, @dejliglama, @afercia, @mukesh27, @iandunn, @pbiron, @allendav, @azaozz, @jesperher, @davidbinda, @ocean90, @mikejolley, @Clorith, @pento, @ianbelanger, @jplojohn, @joostdevalk

The remaining 5.2 work will focus on resolving a few bugs which reside outside of the component but have a privacy feature. These are the two i18n issues affecting privacy notifications (#44721 and #46056) and an improvement (#37782) to the Menus which introduces the Privacy Policy page as an important page in the list.

@garrett-eclipse worked with Meta to update the Privacy Policy to link to the Data Erasure Request page (meta: 4223) and remove Quantcast verbiage (meta: 4216), and to start work on introducing the Data Export Request page (meta: 4224).

The team has begun to flag privacy-related tickets which should be built as feature plugins with the `feature-plugin` manual tag.

V2 Roadmap

The team’s 2019 roadmap has been published to Make. @postphotos wrote a blog post on Make announcing its publication and explaining how the team has structured the plan.

Github repo

@postphotos has gained admin access to the Github repo which we used for the V1 GDPR phase of our work. It has had no updates since 17 May of last year.

The team will now begin actively using the Github repo. The #core-privacy component maintainers have been given owner access to use it to build the feature plugins detailed in the V2 roadmap.

The existing pages on the repo from the V1 GDPR phase of the team’s existence will be retained on the repo and archived for reference.

Conference talks

  • Chris Wiegman – How to Improve Privacy of Your Site for You & Your Users at WordCamp Miami
  • Panel: What you need to know about Privacy and Security in 2019 at WordCamp Miami (no video yet)
  • Regina Dubinska y Jordi Sala: RGPD en la empresa y en WordPress at WordCamp Barcelona

Cross-project privacy cooperation

Please review and comment on the draft plugin privacy audit workflow drafted by @idea15 and Achilleas from the Joomla! privacy team.

The cross-privacy group will be participating in the Mozilla Open Leaders global sprint in May. It is essentially a virtual contributor day or days focused on something over and above the usual ticket scrubs and doc updates. The #core-privacy team participants should brainstorm something fun to do in cooperation with the Drupal, Joomla, and Umbraco privacy teams to advance global internet health.

#core-privacy
#privacy

Gary Pendergast 7:12 am on March 22, 2019
Tags:   

WordPress 5.2 Beta 1 Status Update

WordPress 5.2 Beta 1 was scheduled to be released yesterday, March 21, 2019.

At the time of writing, there are two remaining tickets which need to be committed or punted before beta 1 can be released. Both of these tickets have patches that are ready to commit: they implement the functionality that they’re expected to, any remaining issues with these features can be addressed during the beta period.

With that in mind, the WordPress 5.2 Beta 1 release date only needs to be pushed back one day, to March 22, 2019.

Thank you everyone for the work you’ve put in to get us here! If you have some time to review the tickets linked above, all input is greatly appreciated. 💖

#5-2

Tammie Lister 5:11 pm on March 19, 2019  

Editor Chat Agenda: March 20th

This is the agenda for the weekly editor chat meeting on Wednesday, 20th March 2019, 14:00 GMT.

  • Gutenberg 5.3 Release
  • Tasks Coordination
  • Open Floor

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

#agenda, #editor-chat

Darren Ethier (nerrad) 3:04 pm on March 19, 2019
Tags: ,   

Javascript Chat Summary – March 19, 2019

Below is a 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.

Agenda: Reconciling WordPress and Gutenberg Script Handles

Context | Previous Effort | Slack

Some points there seemed to be consensus on:

  • As needed, existing scripts in WP core will be pulled into the GB repository, exposed as their own package, and then re-registered for use in core.
  • Old handles will still be present for back-compat, but redirect to new handles.

Initial effort regarding this will happen for:

  • shortcode package: https://core.trac.wordpress.org/ticket/44987
  • a11y package: https://core.trac.wordpress.org/ticket/45066

Agenda: How should uncaught errors be handled

Context | Slack

There was much discussion on not only the specific issue (see context) that triggered this agenda but also how this might be generalized. In conclusion, there was some consensus to explore something along the lines of [this solution](https://gist.github.com/aduth/f464f2d549a80716127a7e0d575b102f) in concert with implementing error boundaries in withSelect to see how they interact and work. So short-term focus will be on fixing the immediate issue with errors in subscriber listeners.

Further discussion effort on this will be done in the pull request @aduth will own this issue (in collaboration with others who help).

Agenda: Reusable Scripts

Context: here and here | Slack

This is work towards making the Javascript build setup for plugins much more simplified.

We reached the point where we exposed every tool Gutenberg uses adjusted for external plugins development

@gziolo

Related packages will be published soon.

Action Items:

  • update repository (once package is updated on npm) (@gziolo)
  • dev note about the package linking to the docs and repository (@gziolo)

#core-js, #javascript

Jonathan Desrosiers 9:06 pm on March 13, 2019
Tags:   

Triage Team Meeting Summary – March 11, 2019

The following is a summary of the Triage Team meeting for Monday, March 11, 2019 that took place in the #core room of the Making WordPress Core Slack instance. A full transcript of the meeting can be found here. For more information about the Triage Team, check out the initial blog post.

Primary Goals

The primary goal of the team is to go through all open tickets in Trac to review, triage, and prioritize each one, bringing the number of open tickets down as a result.

While this process is ongoing, recommendations for improvements to the documentation and/or ticket workflow (such as a new keyword) can be made to make the process go more smoothly, but this should be secondary.

Team Members

Anyone can be a part of the team! But, a few people have stepped up to help lead this effort: @desrosj, @chriscct7, @SergeyBiryukov, @karmatosed, and @designsimply. All are available for any questions related to this effort. These team members are in place to make sure that all disciplines are represented in this effort.

Component maintainers are also great resources for help and guidance. A full list of component maintainers can be found here.

Who Can Triage Tickets?

The term Bug Gardener has been used in the past. Triaging and Bug Gardening are really the same things. The team was created to coordinate the effort of going through all open tickets. But, anyone can triage tickets.

Here are tasks that need to be performed on every open ticket:

  • For bugs, test to verify that they are still happening in the latest version of WordPress.
  • Check that the purpose of the ticket is still relevant/valid (changes introduced elsewhere after the ticket was opened may – have rendered some tickets unnecessary).
  • Make sure the ticket has enough information to be properly evaluated.
  • Make sure the keywords on the ticket are accurate.
  • Test patches to make sure they still apply to trunk.
  • Test patches to make sure they still fix the issue.

You can also create patches if that is in your skillset. Any effort to resolve or move a ticket along.

If you are a component maintainer and want some help going through your tickets with component contributors, reach out to one of the team members mentioned above and a date and time can be set for a ticket scrub.

Where to Start?

Getting started will depend on your own personal level of comfort. Here are some areas to jump in.

Newer Contributors

More Seasoned Contributors

If you are a component maintainer or frequent contributor to a specific component, working through a component’s ticket backlog is also a great place to start. Being highly familiar with parts of Core will help when going through those lists.

Some Tips

  • If you have follow up questions for the person that opened the ticket, make sure to use the reporter-feedback keyword.
  • If you are unable to reproduce an issue or think a ticket should be closed but want to give others a chance to weigh in, use the close keyword.
  • If you think all aspects of the proposed changes have been considered and a ticket is ready, add the commit keyword.
  • Make sure has-patch, has-unit-tests and needs-patch, needs-unit-tests keywords are correctly assigned for each ticket.
  • If the ticket needs UI/UX feedback, use the needs-design-feedback keyword.
  • If a ticket needs a specific design, use the needs-design keyword.

Tracking Efforts

If you are planning to contribute time to this effort, please comment below or inform one of the team members noted at the beginning that you are taking part. This allows the team’s progress to be accurately tracked.

Next Meeting

There are no further team meetings planned at this time. When the need for one arises, a date and time will be posted accompanied by an agenda.

Happy triaging!

#triage-team

K. Adam White 7:47 pm on March 13, 2019
Tags: ,   

REST API Meeting Agenda for March 14, 2019

The REST API weekly component chat will occur this week at March 14, 2019 18:00 UTC. If your country has recently adjusted for daylight savings time, please note that this may be a different hour than the past few months.

This week we will be continuing discussion from prior weeks around documentation needs, a canonical REST API authentication plugin, and 5.2 ticket priorities.

All agenda items are welcome, from all teams and contributors; please post them as suggestions on this document.

#agenda, #rest-api

Anthony Burchell 6:04 pm on March 13, 2019  

Media Meeting Recap – March 7 2019

Overview

This post is a summary of the latest weekly Media component meeting, which took place in the #core-media Slack channel, on Thursday, March 7th, 2019. The purpose of these meetings are to move priority tasks forward, provide feedback on issues of interest, and review media focused issues. The focus of this meeting, was around the timing of our meeting going forward.

Attendees: @joemcgill @audrasjb @desrosj @antpb

Transcript: Read on Slack

Media Meeting Time Change

A time change has been discussed in the prior few Media meetings to better fit the schedules of folks all around the world. It was agreed that the time going forward would be Thursdays at 13:00-1400 UTC. We will be starting this schedule starting with the next meeting on Thursday, March 14th, 2019.

Next Meeting

The next #core-media meeting is set for Thursday, March 14, 2019 at 13:00UTC See you there!

#core-media, #media, #summary

Josepha 2:40 pm on March 13, 2019
Tags: , , devchat   

Dev Chat Agenda: March 13

Below is the agenda for the weekly devchat meeting on 2019-03-13 21:00:

  • Announcements
    • 5.1.1 is released!
    • 5.0 retrospective
  • 5.2 updates
    • Feature freeze in ~1 week (Mar 21)
    • Target release in ~7 weeks (April 30)
    • Task coordination
  • 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 in the Making WordPress Slack.

#5-2 #devchat #agenda

Anton Timmermans 12:59 pm on March 13, 2019
Tags: ,   

JavaScript Chat Summary, March 12th, 2019

Below is a summary of 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.

Daylight savings time

Slack Conversation

@aduth proposed to not move the meeting time this instance, because for some people having the meeting an hour later means they can attend. If you have any feedback on this proposal, please leave a comment.

Default webpack configuration

Slack conversation

A default webpack configuration pull request has been merged to wp-scripts. So plugin authors can now do wp-scripts build and that will build their JavaScript into a bundle for the browser.

There was a brief discussion on whether or not the build command should accept a custom webpack configuration. For now this will stay possible. In the longer term the default configuration should be good enough for a lot of users and the Gutenberg webpack config should align with the default config as much as possible.

Pull request for typescript definitions

Slack conversation

The Gutenberg repository received a pull request with TypeScript definitions. This raised the broader question whether these pull requests should be accepted, because these definitions also need to be maintained.

In the chat the consensus was that it is only worth merging these kinds of PRs if the maintainability burden is very low. Given that is not the case it is probably better to not merge the given PR.

This will be decided on next week, please comment here with your ideas on this.

Removing grunt dependency from grunt-patch-wordpress

Slack conversation

@jorbin wants to make the grunt-patch-wordpress tool a general command-line utility that runs without a grunt dependency. Everyone agreed that this is a good idea. The new package will be located inside the monorepo like all other JavaScript packages.

#core-js, #javascript