Dev Chat Agenda: April 25th (4.9.6 week 4)

This is the agenda for the weekly dev meeting on April 25, 2018 at 20:00 UTC / April 25, 2018 at 20:00 UTC:

  • 4.9.6 planning
  • Updates from focus leads and component maintainers
  • Bub scrub communication
  • General announcements

If you have anything to propose to add to the agenda or specific items related to the above, please leave a comment below. See you there!

#4-9-6, #agenda, #core, #dev-chat

PHP Meeting Recap – April 23, 2018

This recap is a summary of our previous PHP meeting. It highlights the ideas and decisions which came up during that meeting, both as a means of documenting and to provide a quick overview for those who were unable to attend.

You can find this meeting’s chat log here.

Chat Summary

The main focus of our recent meeting was reviewing the latest work around the upcoming php info widget.  A reminder that this work is being tracked here.

  • @schlessera presented the latest iteration of the widget for feedback which is this:
php widget screenshot 1

collapsed version:

php widget screenshot 2

Notable features of this iteration:

  • It is accessible.
  • It is more in line with the other widgets.
  • It makes the widget more noticeable when collapsed.
  • It makes use of a dash-icon instead of a notice border for drawing attention

General consensus seemed to favor this latest iteration.  However @johnjamesjacoby brought up some concerns about the verbiage and  language still in the widget.

  • Unnecessary “Click the button” type guidance
  • Running an insecure version of PHP doesn’t mean that a quicker website is a quick update away. (Note, this feedback was also left as a comment in the previous meeting summary post.)
  • Unusual for WordPress core verbiage to have “this is how we do it” type phraseology.

Responses were:

  • Let’s get this feedback on the trac ticket.
  • While most of us don’t completely like what we have now, it’s been through multiple iterations including incorporating suggestions from design and editorial teams.  So its “good enough” for now and we can iterate.

In the latter part of the meeting we focused on the following design comments:

  • Use the color red only if insecure version, otherwise use yellow/orange.
  • Collapse the nag by default.

Although it was brought up that it’s unlikely yellow/orange would ever be displayed because most scenarios will result in an insecure version of PHP prompting the widget to show, we agreed that its trivial to do conditional colors so it will be implemented.

However, the nag being collapsed by default is not a trivial change to make.  There’s no prior art for that with the dashboard widgets.  We decided to defer further discussion on this until the next meeting.

After Hours

Since the meeting @johnjamesjacoby provided additional feedback in the trac ticket and @flixos90 took some of what he suggested and proposed another iteration for the widget:

PHP widget - latest iteration.

Changes made in this iteration:

  • Fix incorrect statement “WordPress has detected that your site is running on an insecure version of PHP, which means that a faster website is just a quick update away.” by removing the second part of that sentence. That furthermore makes it a more clear statement, and the aspect of speed is mentioned in the second paragraph anyway.
  • Remove the whole last section that essentially just revolves around the user needing to click the button. It helps further shortening the copy, as requested by the design team, and was redundant.
  • Left-align button and make it regular-size, as requested by the design team and in 41191.11.2.diff@johnjamesjacoby We cannot shorten the button text itself, as “Learn more” makes it too unclear this link helps with updating PHP.
  • If the PHP version is not insecure, but only out-of-date, show the icon with yellow color, as requested by the design team. This change is to be future-proof, but note that at this point, it will never be rendered this way because we show the notice only on 5.2 which is insecure.

Next meeting:

Next meeting will take place on Monday April 30, 15:00 UTC in #core-php


  • Followup on the latest iteration of the php widget.
  • Decide on whether the widget will default to collapsed.

A reminder that if you have suggestions about the dashboard widget but cannot make the meeting, please leave a comment on this post (and/or comment in the trac ticket).

Gutenberg, REST API, and you

Fancy yourself some challenging architectural puzzles? Have we got the ticket for you!

As you may know, Gutenberg uses the WordPress REST API as a bridge between the land of JavaScript and land of PHP. There were a whole host of conceptual challenges in translating WordPress internals to REST — and even more we still haven’t solved!

We’d love your help 🙂 Read through and comment on the issues linked below as you have time. Then, if you’re available, join the next REST API office hours for a rousing conversation: Thursday, April 26 at 17:00 UTC

Even more curious? Dive into the entire Gutenberg REST API milestone and all Trac tickets tagged ‘rest-api’.


Dev Chat Summary: April 18th (4.9.6 week 3)

This post summarizes the dev chat meeting from April 18th (agenda, Slack archive).

4.9.6 planning

Updates from focus leads and component maintainers

  • The Editor / Gutenberg Team released v2.7 and published information on how they’re organizing component-specific issues in their GitHub repo. Component Maintainers will benefit from utilizing the specific milestone setup for their component when trying to identify areas that would best benefit Gutenberg. There are also additional milestones for a11y and docs.
  • The GDPR Compliance Team published notes from their recent meeting covering recent deployments, available resources, plugin dev guidelines, and the addition of a privacy section to the readme.txt file
  • The PHP Team published notes from their recent meeting
  • The Media Team published notes from their recent meeting covering a time change for their meeting (to Thursday’s at 20:00 UTC) and their main focus on a Gutenberg Media triage
  • @jorbin looking for a proposal on Make/Core post from team working on the JS reorg / no longer using srcwith a summary and proposed timeline; majority of current info is in #43055

Next meeting

The next meeting will take place on April 25, 2018 at 20:00 UTC / April 25, 2018 at 20:00 UTC in the #core Slack channel. Please feel free to drop in with any updates or questions. If you have items to discuss but cannot make the meeting, please leave a comment on this post so that we can take them into account.

#4-9-6, #core, #core-editor, #core-js, #core-media, #core-php, #dev-chat, #gdpr-compliance, #gutenberg, #summary

PHP Meeting Recap – April 16th

This recap is a summary of our previous PHP meeting. It highlights the ideas and decisions which came up during that meeting, both as a means of documenting and to provide a quick overview for those who were unable to attend.

You can find this meeting’s chat log here.

Chat Summary

  • After some back and forth of discussing the color of the widget title border, we decided that we should go for a contextual coloring for now: orange (as a warning color) for outdated sites, and red (as an error color) for insecure sites. However, only after the meeting, we realized that there would hardly be any occasion for us to show the orange warning-type bar.
  • It is important to not rely on color alone for conveying information, for accessibility reasons.
  • We agreed that the efforts to make the widget less visually jarring should avoid downplaying the sense of alarm too much, as that defeats the purpose.
  • The wording of the widget was rediscussed again. However, the result was confusing because not everyone was referring to the most recent state of the widget. We finally didn’t budge from what was concluded last week: the editorial version is good with the exception of the word “guarantee”.
  • We discussed adding a visual symbol, like an exclamation mark, that provides more of a visual cue than the red border. I’ve added a new path with screenshots to the patch that does just that:This also makes the widget still quite noticeable when collapsed.

Next week’s meeting

  • Next meeting will take place on Monday, April 23th, 2018 at 15:00 UTC in #core-php.
  • Agenda: Discuss latest version and the use of the exclamation mark symbol.
  • If you have suggestions about this but cannot make the meeting, please leave a comment on this post so that we can take them into account.

#core-php, #php, #summaries

4.9.6 Schedule

The following is the current 4.9.6 release schedule:

Important Dates

  • Beta: Tuesday, May 1st.
  • RC: Tuesday, May 8th.
  • Release: Tuesday, May 15th.

Bug Scrubs

  • Tuesday, April 24th at 1600 UTC
  • Thursday, April 26th at 1600 UTC
  • Tuesday, May 1st at 1600 UTC
  • Thursday, May 3rd at 1700 UTC
  • Tuesday, May 8th at 1600 UTC
  • Tuesday, May 15th at 1600 UTC

GDPR Meetings

The GDPR compliance group meets in the #gdpr-compliance channel in Slack every Wednesday at 1500 UTC.

4.9.5 Feedback: leading a WordPress minor release

WordPress 4.9.5 was released a couple of weeks ago, at the scheduled time and without known issues.

We (@audrasjb and @danieltj) had the pleasure to co-lead this minor release of the CMS, with @sergey‘s invaluable help as deputy and @jbpaul17’s mentorship. For this release, we were two co-leaders, contributing to the core for a short time, and none of us had core committer status. Thank you all again for trusting us for this task.

Below you will find some feedback and tips we wanted to share with you and we hope this will encourage others to get involved in such an adventure.

To lead a WordPress release, you don’t have to be a core committer,
you have to deeply care about the WordPress open-source project.

Initially, we wondered how the two of us could claim to run a WordPress release without commit access.

In fact, there are many tasks that are not related to the commit action itself, but require a good knowledge of the ecosystem, the people and teams involved and how the release process works. Here are some examples of tasks to do:

  • Triage: sorting tickets and status update. This is a very time consuming task, because you have to dive into each ticket, read all the discussions and check if the patches are ready to land in your minor version or not.
  • Bug scrub meetings: these take place in the #core Slack channel and is about sorting Trac tickets to check if the patches and improvements are on track. You have to ask the Component Maintainers, designers, accessibility specialists or focus leads to help their resolution. We must plan a bug scrub a week or two prior to the release.
  • Dev chats: the weekly meetings of the Core team to discuss progress of the current release, to talk about future releases and to focus on particular points. I had a hard time on that side for the first dev chat I led with the launch of a lively discussion around Gutenberg’s merge proposal and WordPress versioning. In this kind of situation, you have to stick to a rational approach and try to allow everyone to express themselves.
  • Post writing, Trac tickets answering, codex editing and all stuff related to communication. This is very time consuming, so prepare it carefully.

You must also organize yourself for the release process. The complete process is detailed in this handbook: Releasing minor version.

Key moments of a WordPress release

  • D-30 to D-15 – here you are, leading the next minor version of WordPress:
    • You should go around all tickets tagged for this minor version. Take time to read each ticket carefully. During your bug scrubs, you’ll have to be comfortable with each of them, especially with their progress and last discussions. Feel free to get in touch with the related Component Maintainers.
    • Feel free to check out other tickets tagged for the next major release and are already committed. It is quite possible to bring them back to your minor if they are self-contained fixes (and not enhancements) and do not result in any new file being created in WordPress core. We were able to repatriate 5 or 6 patches WP 4.9.5. Personally, I managed a spreadsheet with all the tickets to watch. This document helped me a lot later.
    • Prepare each bug scrub and dev chat in advance: it’s better to copy and paste at these meetings so you can follow the discussions as well.
    • Ask for access to write posts on Make/Core and to be able to notify contributors in the core Slack channel with @here command.
  • D-15 – Beta release:
    • Last bug scrub: all tickets must be committed in the branch. Those who are not ready must be “punted” to the next release. Do not take any risks.
    • One day before, contact lead developers to make sure someone will be available to build your RC package. Do not make the same mistake we made: we ended up with a ready beta but no one to build the package. You must warn Mission Control people in advance!
    • Publish your post on Make/Core : reuse previous posts format and indicate changes so people can test your beta.
  • D-7 – Release candidate:
    • Final Bugscrub: Some last tickets may be committed for RC, but they must have been checked by an experienced core-committer and approved. Besides, two checks are better than one.
    • One day before, contact Mission Control to make sure someone will be available to build your RC package.
    • Publish your post on Make/Core.
    • Bump version number and update changelog for all concerned bundled themes. Here is the standard Trac ticket I made.
  • D-2:
    • Get in touch with the Akismet team to check if a new version is ready to land in the release.
    • Get in touch with the people in charge of bundle themes and ask them to prepare to deliver a new release of the related themes on
    • Get in touch with Mission Control team and ask them for their availability for the D-day.
  • D-1:
    • Get in touch with the Security team (usually they will come to you) to know if security patches will land in your release (we had three security patches). Obviously, this information is confidential, you can not communicate it.
    • Prepare the changelog of the new version with the complete list of changes for the Codex changelog (if the release contains security patches applied to all the supported branches, it would be necessary to make a new page for each version!) And for the Make/Core post.
  • D-Day:
    • Build the packages (current branch + previous branches if a security patch is delivered) with Mission Control team.
    • Ask Meta team to prepare the list of contributors of the release and to update credits API.
    • Prepare to publish the Make/Core Post and the /News Post, they must be published right after auto updates start.
    • Prepare some standard announcement such as “@committers please refrain from committing while we package the 4.9.5 release.” or “Heads up to everyone following along: We’re in the process of releasing right now. You’ll see some builds appear in this channel, but we have not released until there is a new post on Please do not tweet, publish, or otherwise announce a release until there is a public post about it on” for Slack, to repeat regularly during the build process.
    • Prepare local test instances to test each package of each version of WordPress on different PHP environments. Hopefully, other contributors can help you test the packages on their side.

Once launched, that’s the big day. The release is built and auto updates will be done on WordPress installations around the world. Feel free to ask the Mission Control for some statistics – the figures are incredible. Unfortunately, it is not publicly available, but you will certainly be pleased to know in real time the number of people who are enjoying your work.

At the next devchat, you will carefully follow the feedback from the Support Forums team who will give you feedback from users. Fortunately, in our case, nothing went wrong.

Various remarks

  • Remember to warn the people who have Mission Control access a day or two before each release (beta, RC, final release). Without them, you can’t do anything! In our case, we did not manage the beta and the RC very well and only succeeded at the last moment. Thank you for those that helped, who were understanding and caring.
  • An issue when you are relatively new in Core development is to find the right people to contact. Do not hesitate to get in touch with as many people as possible, they will put you touch with the people who can help you. Remember: you can’t build a WordPress release alone.
  • Do not hesitate to get in touch directly with the people who can help you: Component Maintainers, Focus Leads, Theme and / or Plugin Teams, Mission Control, Security. A little introductory message at the very beginning of the release does not hurt, and everyone will be very happy to help you if needed.
  • Attend as many component/focus meetings as possible. Some changes may affect your release and it allows you to know how specific tickets are doing.
  • Plan about three evenings a week to work on the release, during a month. It depends on your timezone but in my case, I had to book at least every Tuesday and Wednesday evening, sometimes until very late at night. Outside, you will also follow what happens in the tickets throughout the week. Tell your boss to get some time for it (thanks to my agency for giving me some time during office hours).
  • Organize well so you do not have any last minute surprises. For example, we were ready to integrate the “Try Gutenberg Callout” or not, and we considered both solutions, whether on the general organization or during changelogs writing and blog posts on Make/Core.
  • If you are running as a co-lead (which is better), alternate the lead equally so that everyone can enjoy the experience of triage, bugscrubs, developers chats and the whole release process.
  • [more personally] If you are not a native English speaker, it’s not the end of the world: focus on putting your ideas first. Nobody will reproach you for not speaking perfect English. WordPress contributors are kind, understanding and professional people.
  • Enjoy all this because time flies!

In conclusion, leading an open source project is above all, rewarding and difficult. It’s no easy feat to manage a team of volunteer contributors and ensuring things run smoothly is a challenge in and of itself, let alone the bugs! Constant communication and asking questions will always put you ahead. No one should feel ashamed to ask an easy question and those kinds of questions are very welcome. Sharing knowledge is more powerful than feeling bad that you don’t know the answer. You should also feel like you can lead too. This doesn’t mean telling people what to do, but being firm and leading and making decisions makes everything move forward much more quickly. To sum up, the human part is just as critical as the technical part of the project.

What’s new in Gutenberg? (18th April)

This release introduces a number of visual refinements around block controls (hover areas, link modal, Classic block), a new block for pagination, and pushes much of the Plugin API out of its experimental stage. Thank you to all the contributors for their efforts, and welcome to the new faces seen throughout the release cycle!

Source for the demoed plugin

2.7 🥨

GDPR Compliance Chat Agenda – April 18

Agenda proposal:

  • A note on Privacy by Design and Cookies
  • Tickets to go out with WP 4.9.6
  • Erasure and export tickets (43546, 43551, 43602, 43637)
  • Owners for tickets
  • Open discussion

Join us on slack at 15:00 UTC.
Open trac tickets
#gdpr-compliance, #agenda

Dev Chat Agenda: April 18th (4.9.6 week 3)

This is the agenda for the weekly dev meeting on April 18, 2018 at 20:00 UTC / April 18, 2018 at 20:00 UTC:

  • 4.9.6 planning
  • Updates from focus leads and component maintainers
  • General announcements

If you have anything to propose to add to the agenda or specific items related to the above, please leave a comment below. See you there!

#4-9-6, #agenda, #core, #dev-chat