Dev Chat Summary: May 1

Announcements

Josepha (@chanthaboune) has published a 5.0 retrospective wrap up. There are two questions at the end of the post that you are encouraged to discuss in the comments. Thank you for the time and care you have put into this, Josepha! You can find this retrospective wrap up at the following post:

5.2 updates

RC2 is planned for tomorrow with the target release date ~5 days (May 7).

Josepha brought attention a few items pending:

  1. #47093 – related to the recovery mode email translations. There’s a potential solution being worked on, but it needs review.
  2. #47070 – related to the Recovery Mode Exit button. Design input and a patch is needed, and then it will also need review.
  3. #46901 – related to the About page. A final patch is incoming that will need review.

Most tasks pending for the above tickets have an owner, but it was mentioned by Jonathan (@desrosj) that particular testing and attention to #47093 – recovery mode email translations is encouraged and appreciated.

@audrasjb asked for an idea of the timing for RC 2 tomorrow. Josepha mentioned that it will likely be in the windows of between 1430-1630 UTC and again around 2030 UTC. The earlier window is preference.

5.3

It would be great to start planning scope/teams/timing etc. for 5.3. (potential agenda item for next week!) Jonathan mentioned that we may be able to start the 5.3 branch in trunk after RC2 has released.

Open Floor

WP Campus’ Accessibility audit released today

A big thank you to WP Campus for this important initiative! You can find the blog post announcing the audit here: https://wpcampus.org/2019/05/gutenberg-audit-results/

#5-2, #core-editor, #design, #devchat, #summary

#core-privacy April update

This is a cumulative update for #core-privacy office hours and bug scrubs held in April 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 15:00 UTC.

5.2 release

5.2 has been a monumental team effort by core-privacy. The team has shipped all 24 of its tickets earmarked for the release. These included 15 bugfixes and 9 enhancements.

Special props go to @garrett-eclipse for being the driving force behind the team’s 5.2 ticket success.

The “biggest win” was #44005, introducing the new privacy policy page helpers.

General fixes include:

#46098 – The Privacy Policy guide help notice is now displayed on both the classic editor and the block editor.

#44707 – Users are now able to make additional requests when identical previous requests are in a complete or archived state.

#44644 – The ‘Download Personal Data’ admin action no longer triggers a completion of the request.

Also in 5.2 some privacy nags were removed; post-4.9.6, these notifications had served their purpose:

#45999 – Remove the Privacy Pointer

#46819 – Remove the Privacy Bubble

Some i18N-Privacy wins were:

#44721 – The Personal Data Erasure Fulfillment email is now in the User’s Locale

#46056 – The Personal Data Export email is now in the User’s Locale

Tickets shipped since the March team update included #44175, #44644, #44047, #46819, and #46098. Props @knutsp, @desrosj, @joshuawold, @birgire, @mechter, @subrataemfluence, @xkon, @saimonh, @audrasjb, @dejliglama, @ianbelanger, @iandunn, @pento, @sergeybiryukov.

@earnjam wrote a post in Make/Core on the developer-focused privacy updates in 5.2.

@williampatton wrote a dev note in Make/Themes on the new privacy policy page helpers coming in 5.2.

5.3: export and erasure

For 5.3, @xkon would like the team to focus on finalising all outstanding issues with export and erasure requests. @audrasjb has given @xkon access to his repo for the front-end forms for export and erasure, with a view to using this as our first team feature plugin. (#44013)

5.3: privacy notice updates

The team has discussed #44538, #44669, #46687 as an opportunity for collaboration with the #design team.

Plugin privacy audit

@idea15 has finished writing beta version 1 of the plugin privacy audit workflow, with the help of feedback from many team members and plugin developers. Please feel free to test the workflow on your plugin and provide the team with feedback in #core-privacy.

WordCamp Europe

@idea15 has signed up for a slot for the team at the WP Cafe at WCEU. This will be a friendly hangout and chat space with no set agenda.

As with last year, #core-privacy will have a team table at the WCEU contributor day. As with last year, @idea15 @xkon @pputzer @postphotos will take turns secretly disconnecting the wi-fi.

Cross-project privacy cooperation

Members of the #core-privacy team who participate in the cross-project privacy initiative will be participating in the Mozilla Global Sprint in May to standardise file formats for data portability exports and imports across our CMSes, and to identify the export and import functionality which may need to be created within each project. All are welcome to join in. Dates TBC.

Conference talks

New on WPTV:

@rhyswynne at WordCamp Edinburgh 2018: How to integrate the 4.9.6 privacy features into your plugin

@mainplus at WordCamp Belfast 2018: Follow the data

@riankinney at WordCamp Rome 2018: The differences between U.S. and EU privacy law

New talks:

@idea15 participated remotely in a privacy BOF at Drupalcon Seattle on behalf of the #core-privacy team.

@pputzer gave an outstanding talk at WordCamp Vienna on 27 April focusing on active #core-privacy tickets from a developer/site owner perspective. The slides are available here.

Other matters:

@javorszky started a review of the wp.org privacy policies which is currently active and available for discussion & review here.

Dev Chat Summary: April 24

Announcements

Josepha (@chanthaboune) is working on bringing us a 5.0 retrospective wrap up, a project digest, and a team lead interest form. She is planning to publish the retrospective wrap up this week and potentially the project digest soon after in the following week. Thank you, Josepha!

5.2 updates

#46898 WSOD Protection could use some copy review

RC1 is planned for today, with the *target release date in ~2 weeks*

Josepha brought attention a few items needing help:

There were 11 tickets open in the 5.2 milestone but that is now down to 3 as of writing this summary. @pento worked through a bunch the evening prior to devchat and @sergeybiryukov has been lending a hand today. Many of these will be moved out of the milestone, but if there are any still at this link, feel free to discuss or do the next step.

The about page outline will be ready for RC1 and will be final in the final release. Most of text should be in by RC-1 but it is not “frozen” in this time period.

Dev Notes

There are a few dev notes that are still in draft. @jeffpaul is working through the field guide and adding placeholders for those. It would be much appreciated if you’d finalize your notes so we can include them! Ideally these would release along side RC1.

Please use the following link as a list of what is pending for dev-notes: link here. If the dev note has been made, please remove the needs-dev-note keyword. 🙂

Open Floor

Influx in Forum issues/Trac Tickets

There was discussion around the continued cadence and nature of Minor/Major releases. @joyously said that she has noticed an influx in forum posts focused around bugs. Joy reminded us that directing folks to create tickets in the forums will help greatly in identifying common bugs. This also serves as a reminder that there are teams for triage in both Trac and the Gutenberg Github repo that would greatly appreciate the help. The Gutenberg triage has recently moved to a weekly cadence and the times are as follows:

Gutenberg #core-editor triage times are – Monday at 13:00 UTC

Gutenberg #design triage times are every Tuesday at 16:00 UTC

@jorbin punted #46293 as there was no decision made and there is a need to freeze strings. Many thumbs up emojis agreed. 👍

#5-2, #devchat, #summary

Dev Chat Summary: June 20th (4.9.7 week 5)

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

4.9.7 planning

  • Leads nominated so far: @sergeybiryukov able to help as deputy (e.g., committing, backporting); @danieltj, @tristangemus, @pbiron, and @danielbachhuber open to help contribute during 4.9.7
  • Potential focus for 4.9.7 so far “Try Gutenberg” prompt and privacy fixes
  • Release timing for 4.9.7 will be determined after a release lead is named
  • No confirmed interest in release leads from other team reps and component maintainers or from WCEU, but #design team likely in future minor releases
  • Looking to increase diversity in release leads by asking for nominations or suggestions outside just devchat and summary posts, please share any ideas you have on this… thanks!
  • For those with interest and availability, please review the Releasing Minor Versions handbook page and the Release leads feedback on 4.9.5 post
  • Will look to make decision on 4.9.7 release leads in next week’s devchat

Devchat coordination

  • @jeffpaul will be offline most of July, so we’ll need someone to help coordinate/run devchats
  • So far @joemcgill, @audrasjb, and @antpb have graciously offered their time, hoping for 1-2 more people to help to help share the load
  • If you’re open to collecting agenda items and publishing an agenda, running the actual devchat meeting, and/or publishing a devchat summary then please comment here or ping @jeffpaul if you’re able to help out… thanks!

Updates from focus leads and component maintainers

  • The Gutenberg team would like to encourage testing of the next few releases as they get closer to feature complete
  • The JavaScript team shared an update on the process of adding inline docs, so if you’re interested and able to contribute please check it out. They also posted a summary of their meeting covering documentation, polyfills, and deprecation strategy for WP JS code.

Next meeting

The next meeting will take place on June 27, 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-7, #core, #core-js, #dev-chat, #gutenberg, #summary

PHP Meeting Recap – May 28th

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

  • We started with discussing Trac ticket #43986 – Disable “Install Plugin” button for PHP required version mismatch and the currently posted patches. An immediate goal was to distill the different approaches we’ve been exploring so that the #design team can give specific feedback on these approaches, instead of only asking for general and vague “feedback”.
  • Questions we’ve distilled for that ticket:
    • Where does compatibility breakdown go: 1. under install button, 2. in bottom panel, 3. hidden away under “More Details” modal
    • Whether to show compatible/not-compatible state, or only show non-compatible state and stay quiet for compatible state
    • Whether to use (colorized) icons or not
    • Whether to show current/required version numbers or not
    • If both PHP and WordPress version are insufficient: 1. show both, 2. show only WordPress (easier to fix), 3. show only PHP (more problematic)
  • Both @afragen & @SergeyBiryukov had provided similar patches, which differed in their general approach of how to integrate into existing Core behavior: while @afragen added actions to make the new blocking functionality extensible, @SergeyBiryukov opted to hardcode the integration into the existing Core flow instead.
    After some deliberation, we decided to go with the hardcoded approach, to avoid introducing new actions (that are not needed for now) that would entail additional documentation, maintenance and backward compatibility effort.
  • @SergeyBiryukov stated that we could target 4.9.7 for this if we manage to get it ready soon.

Post-Meeting Updates

  • We agreed that, although we could filter out incompatible plugins, we prefer to show them with a disabled “Install” button, as this provides the incentive we need to encourage people to upgrade.
  • The #design team discussed the #43986 Trac ticket and provided some feedback. Mainly, the bottom area should be cleared and used completely for providing meaningful feedback if an “Install” action is being blocked.
  • @MelChoyce collaborated with @afragen directly to produce a new version of the patch that matches this #design feedback. This seems to be the screenshot that reflects the current state of the patch best:Plugin search result: "Incompatible plugin" error

Next week’s meeting

  • Next meeting will take place on Monday, June 4th, 2018 at 15:00 UTC in #core-php.
  • Agenda: Continue work on the “Disable Install button” patch.
  • 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, #servehappy, #summary

PHP Meeting Recap – May 7th, 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

At this meeting there was some continued conversation around plugins & theme php version requirements (see parent ticket here)

  • @sergey has made some progress on technical restrictions
  • #design feedback will be needed as a part of implementing how restrictions are communicated to the user.
  • Initial goal for this is block installation of plugins in environments that don’t match php requirements for the plugin.
  • @flixos90 is going to get in touch with the design team regarding feedback on the mockups.

Also on the agenda was continued conversation around design/layout work for the PHP upgrade page. We took a look at this mockup that was done by @jaymanpandya, however for the most part we felt that in order to progress on this, the feedback needs to come from the #design team itself and those involved in the design of the overall WordPress.org site. To that end, @flixos90 has created a ticket in meta for tracking this and this is a callout to anyone involved in #design (and particularly with regards to the overall design of WordPress.org and how this would fit in with that) to review the current mockup and add comments.

Next Meeting

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

Agenda:

  • Followup on php requirement restrictions for plugins/themes (hopefully with some design feedback).
  • Followup on PHP upgrade page design feedback (if there is any).

#php, #summary

PHP Meeting Recap – April 30th

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

  • We first discussed whether we could have the current widget implementation backported to the upcoming minor release 4.9.6. @desrosj was positive about doing this, but left it open for a final review and someone with the willingness to actually commit it. One benefit would be to include this with the privacy policy changes, which has translators already be aware that a portion of new text strings need to be translated. Also, getting it in as soon as possible will finally allow us to get real feedback on its reception and effectiveness.
  • The “Upgrade PHP” information page needs a visual overhaul. It currently is a pure wall of text, and any change in that regard will be an improvement at this point. @schlessera will work on changing the page for a few quick wins to make it more digestible, and the discussion with the #design team needs to be relaunched.
  • As the first two components of the “Servehappy” initiative are now in a usable state, it is time to focus on the third component: enforcing the “Requires PHP” plugin header information.
  • There are several different mechanisms that need to be changed for enforcing the PHP version requirement, and we agreed to split the main ticket up into smaller subtasks so that blocking issues in one will not block progress in others.
    Here are tickets for the current subtasks:
    1. Disable “Install” (plugin) buttons – #43986
    2. Block updates to new plugin releases – #43987
    3. Allow filtering plugin searches by required PHP version – #43989
  • @afragen has already built a proof of concept that shows a basic implementation for blocking updates. This immediately points out a problem with the current API, which can only serve the plugin information for the latest release of a plugin. If we need to cycle to prior versions to do something like “find the latest version that still runs on PHP 5.2”, we’ll have to work on infrastructure changes as well.
  • Blocking updates does have security implications. We want to block updates to new versions that would bump the required PHP version past a version the server provides, but at the same time, we still want to provide the possibility for plugin authors to push security updates.

Post-meeting update

  • The Servehappy nag widget was not included in the beta of release 4.9.6. We should work on getting it backported early in the 4.9.7 release cycle.

Next week’s meeting

  • Next meeting will take place on Monday, April 7th, 2018 at 15:00 UTC in #core-php.
  • Agenda: Discuss how best to relaunch the #design process and go over the individual tickets for enforcing the “Requires PHP” header.
  • 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, #summary

PHP Meeting Recap – March 19th & 26th

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.

Chat log from March 19th
Chat log from March 26th

Chat Summary

Dashboard widget (#41191)

  • The voice of the widget text has been adapted to better match the overall WordPress feel.
  • The accessibility concerns that were raised have been addressed.
  • The widget currently looks like this:
  • The Trac ticket was flagged for ui-feedback and we are now waiting for the #design team to be able to go over the ticket. Once all of their feedback has been processed and incorporated, the version in trunk will be ready to discuss backporting it to the next minor release (4.9.6).

PHP version requirements for plugins & themes (#40934)

Next week’s meeting

  • Next meeting will take place on Monday, April 2, 2018 at 15:00 UTC in #core-php.
  • Agenda: [Go over #design feedback and] discuss how to proceed with plugin requirements.
  • 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, #servehappy, #summary

PHP Meeting Recap – November 6th

This recap is a summary of this week’s 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.

The meeting’s chat log.

Attendees: @bpayton @flixos90 @jdgrimes @mte90 @nerrad @overclokk @psykro @schlessera @vizkr

Chat Summary

The agenda for this week was to review the suggestions @flixos90 has worked on for the “Before Upgrading PHP” section that is available in the Google document, taking the past weeks’ discussions into account.

As other important topics had come up after the agenda had been laid out though, the discussion ended up revolving around different topics, only taking a short peak at the document towards the end of the meeting. Here is the discussion summary:

  • @flixos90 shared some great news about the tool that the XWP team has been working on, which had been mentioned a few times before in other meetings: The tool automatically scans all plugins in the plugin repository for their usage of the WordPress coding standards and, more important for the PHP team, their compatibility with different PHP versions from 5.2 to 7.x. The project is going to be an official part of the repository, and all of this will be handled through an external API. The results of the scans will be displayed on the respective plugin page, and the PHP compatibility checker could leverage that data as well. The API will even be able to scan plugins and themes which are not part of the repository, by temporarily uploading them. This will allow to test even paid or custom developed plugins and themes. That part will not be exposed through any UI in the initial release, but it will be possible through the API.
  • @nerrad commented that this will likely require some changes on the Servehappy page copy that exists so far. These changes will likely be minor though and most importantly take away some points of uncertainty that with that tool at hand won’t matter anymore.
  • It would make sense for the PHP Compatibility Checker to leverage that API, so it needs to be discussed with the responsible people at WP Engine what steps should be taken here. The new API could either be used in addition for more accurate results, but it may possibly even be better to replace the current mechanism with it entirely, as it would improve speed significantly because it could in many cases use data that has already been gathered before rather than running the expensive checks on the server.
  • The above two topics should be discussed in detail once the API has been officially released to the public.
  • @psykro asked whether it would be possible to change the meeting time or host a second meeting. Everyone who responded was open to a change, however it should preferably remain close to when it’s currently scheduled (every Monday at 19:00 UTC). If you are interested, please leave your vote(s) on this Slack post.
  • @mte90 asked about the new plugin headers for a minimum required PHP version and specifically about when the integration with core for it should be developed. While core should not include any PHP-related notices or warnings until the Servehappy page is published, it makes sense to start work on it before. This will not be a major topic for the PHP meetings for now, but should mainly happen in its Trac ticket #40934, unless a rather complex topic comes up which would benefit from a discussion in a meeting. @psykro, @schlessera and @mte90 expressed their interest in working on this. Mockups for the visual side of things should be created early, and the #design team should be asked for help with this. Since the project will likely involve quite a bit of code and it’s not optimal managing this solely through Trac, it was suggested to go either with a plugin-first approach or use a GitHub fork of the WordPress development repository.
  • After that, attendees started reviewing the sections in the Google document and added some comments and suggestions. @nerrad highlighted that the last section about contacting a developer should only be targeted at those site owners that already have an ongoing relationship with one, or at least already know one. People who have never hired a developer are unlikely to do so for a “random” PHP upgrade. More in-depth review and discussion on the Google document was postponed to next week’s meeting.

Next week’s meeting

The next meeting will take place on November 13th, 2017, 19:00 UTC as always in #core-php, and its agenda will be to actually review the initial suggested copy for the “Before Upgrading PHP” section so that it can be passed on to the marketing team afterwards. 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. See you next week!

#core-php, #php, #summary

Customize Meeting Summary: September 25th

This post summarizes the Customize meeting from September 25th in the #core-customize Slack channel (Slack archive).

Participants: @westonruter, @melchoyce, @obenland, @sirjonathan, @joemcgill, @sayedwp, @jbpaul17. Misbehaving: @tracbot.

Discussion highlights

Drafting and Scheduling

Gallery widget

Customizer UX for themes

Bug scrub

  • Trac listing of the enhancements and feature requests milestoned for 4.9 for the team
  • #39930: docs changes, so changing this from enhancement task ticket
  • #28721: related to and will be resolved when #39896 is merged
  • #34843: will be resolved by #37661
  • #35827: no one working on this, so punting to Future Release
  • #40527: punting
  • #40922: punting
  • #37964: will be picked up by @sayedwp when #39896 is done
  • #38707: CSS highlight part is implemented, but “revisions, selection, per-page, pop-out” is not
    • “per-page” aspect has been yanked from consideration in the near future
    • will work on revisions, selection, and pop-out in a feature plugin outside of core
  • #39275: likely to be resolved in #39896
  • #40104: @bpayton hopes to have a patch up by Friday
  • Topic for future devchat: What is the difference between a feature request and a feature project. It’s not really formalized. Are we deeming “feature request” to be the same as “feature project”?

Next week’s meeting

The next meeting will take place on Monday, October 2, 17:00 UTC in the #core-customize Slack channel. Please feel free to drop in with any updates, questions, or tickets you’d like to discuss. 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.

#core-customize, #summary