Dev Chat Summary: May 16th (4.9.6 week 7)

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

4.9.6 planning

Updates from focus leads and component maintainers

  • The REST API team has an update on their progress on closing the gap in the Gutenberg merge proposal milestone as well as notes from their office hours last week. Join them Thursdays at 17:00 UTC if you’d like to chat through any questions you have, they especially want input from long-time contributors and leads on the register_meta changes (see #38323).
  • The JavaScript I18N team posted notes from their meeting last week and discussion around extracting strings from JavaScript and loading the actual translations in a way that makes sense. Join them on Tuesday, May 29th at 15:00 UTC to further discuss how to handle translation loading.
  • @omarreiss posted about adding JavaScript build step and folder reorganization as the first part on preparing for WordPress’ JavaScript future. Please give that a review and provide feedback or help as you have time/interest.
  • @rianrietveld posted about Pair programming on the contributors day to join accessibility experts and Gutenberg developers and work to close the 11 remaining issues in the accessibility merge proposal milestone for Gutenberg. If you are a developer that knows your way around the Gutenberg code and are going to WordCamp Europe in Belgrade, then please ping @rianrietveld… thanks!

General announcements

  • @danieltj working on merge proposal for Dark Mode (see #41928), currently working on review for the WP Coding Standards and an a11y review
  • @presskopp looking for UI feedback on #35288, especially if “Search Engine Visibility” be reflected under Settings >> Privacy

Next meeting

The next meeting will take place on May 23, 2018 at 20:00 UTC / May 23, 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-i18n, #core-js, #core-restapi, #dev-chat, #gdpr-compliance, #gutenberg, #summary

Dev Chat Summary: May 9th (4.9.6 week 6)

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

4.9.6 planning

  • Thanks to all the contributors working on 4.9.6 so far, everyone has been doing a great job!
  • Planning on a final bug scrub tomorrow (May 10th) at 14:30 UTC then packaging the release candidate at 20:00 UTC
  • There are still 13 open bugs that need final testing and feedback. The delay was a difficult decision, but it is giving us the amount of time needed to fix all of these little bugs.
  • Majority of bug tickets actively being worked on in #gdpr-compliance
  • @allendav and proof reading volunteers are working on handbook content to help devs work with the new privacy tools. Those will be supplemented by dev notes ASAP.
  • Beta is still available for testing, any and all feedback is welcomed
  • Reminder that the release is scheduled for Thursday, May 17th

Updates from focus leads and component maintainers

  • The REST API team posted a summary from their last meeting covering decisions around `register_meta()` and documentation. Decisions are being made so if lead devs or component maintainers have input then please take the time to review and join the discussion. Many thanks to those who’ve joined the component lately, some important stuff has been getting closed out. #43998 is a priority and current needs a patch.
  • The Gutenberg team released v2.8, continue to iterate on regular releases, and thank everyone involved.
  • The PHP team posted recaps from their last two meetings covering Servehappy, PHP version requirements for plugins & themes, and the PHP upgrade page.

General announcements

  • @mikeschinkel: looking for input on #12955, its 8 years old but has recent discussions that could use feedback so those interested in contributing take the best approach

Next meeting

The next meeting will take place on May 16, 2018 at 20:00 UTC / May 16, 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, #dev-chat, #summary

REST API Meeting Summary: May 3rd

This post summarizes the REST API component team meeting from May 3rd in #core-restapi (Slack archive).

Decisions around register_meta()

This meeting revolved around finding decisions on remaining questions regarding the approach for adding subtype support to register_meta(). Please read the announcement post for the meeting for background and context.

  • It was decided to go with the fourth approach outlined in the announcement post: Every registration of a meta key is accepted, regardless of whether the same meta key already exists on the same object type in another way. Meta keys registered for an object type and subtype will take precedence over meta keys only registered for an object type (i.e. less specific). This allows us to not having to deal with conflicts. Existing calls without using object types will continue to work – while they are now fallback, chances of a conflict are generally rather low in this way. Nonetheless, a major part of these improvements will involve precise documentation and education (more on that below).
  • Easy-to-understand wrapping functions will be introduced, such as register_post_meta(), unregister_post_meta(), and the same for terms, comments and users. In those functions, we can significantly help DUX: Instead of mentioning the very abstract term “object subtype”, we can here refer to it as the more common terms “post type”, “taxonomy”, etc. respectively.
  • New filters sanitize_{$object_type}_meta_{$meta_key}_for_{$object_subtype} and auth_{$object_type}_meta_{$meta_key}_for_{$object_subtype} will be introduced for metadata sanitization and metadata capability handling for specific subtypes. If one of these two filters is being used for the given variables, the existing sanitize_{$object_type}_meta_{$meta_key} and auth_{$object_type}_meta_{$meta_key} will not be executed – again, this is because metadata registration for an object type and subtype overrules metadata registration for only an object type.

An updated patch with the above changes is in place to test the current approach, available on the ticket #38323.

Documentation & Recommendations

The existing register_meta() function has not yet seen wide use in REST API-related plugins, so the transition to this new behavior should be smooth. However, should developers continue to omit object subtypes or fail to properly prefix their meta keys, over time the chance of conflicts between or within plugins will increase—therefore precise documentation and education are necessary to make all of this work in the long run.

To aid the transition to the new behavior, it will be recommended to switch existing calls to register_meta() over to include an object subtype. Additionally, we will no longer encourage direct calls to register_meta() when a wrapping function like register_post_meta() is available—this is in line with how it is currently preferable to call get_post_meta() over get_metadata( 'post' ), for example. We will also re-emphasize the importance of prefixing meta keys to ensure uniqueness.

Related Issues

Something that we will want to consider in the future is how to deal with meta keys of the same name that are registered for exactly the same object type and the same subtype. Currently, the second call would simply override the data registered by the first call. Alternatively, we could make the second call fail, keeping the first one the “winner”. However, this is a general problem in many areas in core (think about register_post_type() for example), so this may not be the appropriate point to discuss such a big topic.

May 10th Meeting Agenda

Next week’s meeting on Thursday, May 10th 17:00 UTC will continue to focus on discussing register_meta(), particularly review whether the current patch is a viable solution. We will also try to find an answer to the last, smaller question of the original announcement post, whether comment types should actually be considered subtypes in scope of metadata registration. If there is time left afterwards, we can also discuss the state of the current directly Gutenberg-related work in the REST API – otherwise this will happen the week after.

Please review the register_meta() ticket #38323 and the latest patch there, and chime in with your thoughts on the ticket or by attending the meeting!

#rest-api, #summary

Dev Chat Summary: May 2nd (4.9.6 week 5)

This post summarizes the dev chat meeting from May 2nd (agenda, Slack archive).

4.9.6 planning

  • Decision to push beta back two days gave us enough time to backport all the things (thanks to @sergey for all the work there)
  • 25 tickets left in the milestone, aiming to get to 10 for beta, will likely punt non-GDPR tickets
  • Bug scrub tomorrow will be at 15:00 UTC instead of 17:00 UTC
  • @azaozz lined up to help package up the beta in Mission Control, process to begin at 20:00 UTC
  • Heavy discussion on where to introduce new menu items as part of #43873, four options outlined:
    • 1) All three under the Tools menu (currently how it is in trunk).
    • 2) The settings page under the Settings menu labeled Privacy, and the tools under Tools
    • 3) A new top level menu item for Privacy.
    • 4) Listing the erasure and export tools under Users, and the settings page under Settings.
  • Summary of decision:
    • Export and erase tools remain under tools
    • A settings page for Privacy Notice is added to the bottom of the Settings menu.
    • @melchoyce to follow up with feedback on that settings page.
    • @desrosj to create a ticket for the pointers needed for this work
  • Reminder that after beta ships tomorrow, RC will be up next on Tuesday, May 8th (see: 4.9.6 schedule)
  • Please feel free to drop into #gdpr-compliance to continue discussions or if you have some time available to help out before beta.

Updates from focus leads and component maintainers

Next meeting

The next meeting will take place on May 9, 2018 at 20:00 UTC / May 9, 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, #dev-chat, #summary

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

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

4.9.6 planning

  • Would appreciate testing help so people working in #gdpr-compliance can land as many of the GDPR tickets as possible in 4.9.6
  • Beta planned for Tuesday, May 1st
  • Expecting to freeze most strings for beta, Polyglots will also need lots of help translating strings coming in 4.9.6
  • #43862 will need some good old-fashioned hand testing when it lands

Updates from focus leads and component maintainers

Bug scrub communication

  • @mindmantra and @desrosj noted that there’s no space on the Meetings page or otherwise to note scheduled Bug Scrubs besides the post that goes out on the topic
  • Would it help to communicate scheduled bug scrubs other than the make/core posts? If so, where/how?
  • Decision to add bug scrubs to the Meetings page for 4.9.6 and reasses after release if that worked well, if so we’ll make that standard for future releases and add to the core handbook

General announcements

Next meeting

The next meeting will take place on May 2, 2018 at 20:00 UTC / May 2, 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, #dev-chat, #summary

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, #dev-chat, #summary

GDPR Compliance Chat Recap – April 11

(full text on slack)

First deploy of ticket #43481

  • Core ticket #43481 is about tabs and placeholders to privacy tools page in wp-admin and a first version has been committed into dev. Goal is to have it inside the 4.9.6 release.
  • These screens will allow the site admin to get validation from the requester follow-up on requests. Requests could come in from different sources (email, phone request, contact page, etc) so a dedicated place is needed.

Announcements: Available texts and where to publish them

Plugin dev guidelines

Privacy section in readme.txt

  • Besides the functions in Core and the upcoming filters/hooks that plugin authors will be able to use, there might also be a need to have privacy related info in the readme.txt
  • The advantages of a section in the readme.txt would be:
    • availability in plain text in downloads
    • parsable, can be displayed in tab on plugin repo
    • translation, since readme is in Core’s i18n tools on translate.wordpress.org
    • Version control
  • The eventual section in the readme.txt will however not substitute the need of having the privacy information also delivered using filters/hooks as the purpose and possibilities are different.
  • Another idea was to add a ‘Privacy URL’ keyword where a URL could be provided to a privacy statement hosted on a website.

Trac tickets: https://core.trac.wordpress.org/query?status=!closed&keywords=~gdpr
GDPR agenda and recaps: https://make.wordpress.org/core/tag/gdpr-compliance/

#gdpr-compliance #summary

PHP Meeting Recap – April 9th

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 design meeting had not taken place at the time to discuss design of the nag, but the topic was discussed later the week, so next week there will be feedback to review. Screenshots of both the expanded and collapsed state of the dashboard widget are present on the ticket #41191.
  • Via the Automattic editorial team, an updated version of the copy for the nag was suggested and uploaded as a patch.
  • The suggested changes were met with consent, especially considering the removal of a rather redundant sentence to continue reading and a fragment focusing on the people working on WordPress (as they are not the group the widget is targeting).
  • The new “PHP Upgrade Required” was approved as well. While mentioning the term PHP which may initially be unknown to the site owner, it clearly identifies the problem, and via the word “required” it is a clear call to action.
  • The one sentence questioned was the following:

    The instructions we provide will guarantee a secure, painless update.

    Particularly the word “guarantee” may be misleading as it is impossible to guarantee a painless update process. @nerrad shared multiple alternatives which he also added to the ticket. There was consent that at least “guarantee” should be replaced with “help with”.

  • An important thought that was emphasized again was that, while upgrading PHP is not that trivial, there needs to be a positive attitude and expressions being used about that in order to motivate site owners to proceed. It must not be too euphemistic though – updating PHP is undoubtedly more complicated than updating a browser for example.
  • Except for the one sentence it was agreed that the revised version is more accurate, on-point and in line with the wording used in core otherwise.

Next week’s meeting

  • Next meeting will take place on Monday, April 16th, 2018 at 15:00 UTC in #core-php.
  • Agenda: Discuss design feedback for the nag, as expressed in their meeting and on the ticket.
  • 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

Dev Chat Summary: April 11th (4.9.6 week 2)

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

4.9.5 feedback

  • @audrasjb wrapping up feedback post, aiming to publish by end of week on experience leading 4.9.5
  • No other feedback, so no urgent need to rush out immediate fixes in 4.9.6

4.9.6 planning

  • @desrosj self-nominated to be co-lead, @melchoyce nominated @allendav to be co-lead, @sergey self-nominated to be a deputy (given desire to have a lead with commit access); all have accepted and will begin planning, many thanks to them!
  • @desrosj to focus on coordinating release, @allendav to focus on GDPR, @sergey to focus on review and commits were needed
  • Will want to line up someone to help with packaging ~48 hours ahead of beta, RC, and release
  • Tentative timeline: beta on Tuesday, April 24th, RC on Tuesday, May 1st, and Release on Tuesday, May 8th (will be confirmed in next week’s devchat)
  • Planning to begin communicating via Make/Core of what’s going into 4.9.6 and will encourage devs to utilize trunk
  • @desrosj and @jbpaul17 to work on bug scrub schedule

Updates from focus leads and component maintainers

Next meeting

The next meeting will take place on April 18, 2018 at 20:00 UTC / April 18, 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, #dev-chat, #summary

GDPR Compliance Chat Recap – April 4

(full text on slack)

Documentation: what texts do we need?

  • A table of contents of the needed information is present on https://github.com/gdpr-compliance/info/blob/master/information-resources.md . @idea15 started on some of them.
  • Some shorter/other texts will be needed to add to core, but can then have links to the final privacy blog: WP default policy, text for new user registration and on user profile screen, technical text about the new functions for developer.wordpress.org , chapter in the plugin handbook
  • After a chat with Mika, the guidelines for developers will be amended so that it's clear that plugins can assist in helping the site compliant but not that installing the plugin will make the site compliant.

Marketing: How to announce the project to the world?

  • @dejliglama reached out to the WhiP linking to make/core in their newsletter. There will be a longer piece later.
  • A paragraph was also create in the Month in WordPress of March
  • A proposal is to get a post out every 2 weeks with a major one on 25-May.
  • The roadmap can be used as a start, but might be slightly too technical for the broader public.

Trac Tickets: Review of specific tickets

  • #43492 was discussed. Data is stored for telemetry but also to make sure websites have the correct (security) updates.
  • A site admin should not have to opt-in, because having a WordPress site without security updates is not acceptable. But a combination of some data (like website URL, IP, etc) might be seen as personal data.
  • More clarification is needed. @pento and @pesieminski should be contacted.

AOB

  • Design should arrive in the next days so Allen and Mike can start with the patches for their tickets.
  • WordCamp Europe workshop: @idea15 will be hosting a GDPR Workshop at WCEU. She is looking for Teaching Assistants that can help her in making it a success. Please comment below (or DM on slack) if you are in Belgrade in June and are willing to support!
  • WordCamp Europe contributor day: @idea15 has been contacted to be ready for questions during Contributor Day (June 14 in Belgrade). Anybody willing to help @xkon, @azaozz and probably @postphotos on that day? Leave a comment or DM.

Actions

  • @idea15: Create a text for marketing (due 2018-04-08)
  • @azaozz: Follow up with Marketing for the above text
  • @casiepa: Add short texts needed in the table of contents

Trac tickets: https://core.trac.wordpress.org/query?status=!closed&keywords=~gdpr
GDPR agenda and recaps: https://make.wordpress.org/core/tag/gdpr-compliance/

#gdpr-compliance #summary

Ain't no party like a GDPR party
Cos a GDPR party don't stop until someone has a question about personal data.
(Heather Burns)