Core-privacy Office Hours Summary – 17 October

Below is a summary of the discussion from this week’s #core-privacy chat. You can read the chat in its entirety in Slack.

Roadmap Progress

There was no roadmap related progress to report this week. The component’s focus until post-Gutenberg remains the 31 bug tickets, with a goal of marking at least 75% of them as ready for commit.

Gutenberg Privacy Review

@allendav, @garrett-eclipse, and @azaozz have been reviewing Gutenberg for potential privacy issues.

In response to concerns about the source of the data presented on, @allendav will add a note to the footer on that site clarifying that the post counts come from Jetpack-connected sites. @allendav also reports that there is no Automattic tracking code in Gutenberg, and that if a site has Jetpack and Gutenberg installed, some of Jetpack’s Gutenberg blocks are loaded from Automattic’s CDN.

Related to CDNs, @azaozz confirmed that reliance on unpkg will not be an issue once Gutenberg is merged into WordPress Core. Third party resources are loaded from a CDN when Gutenberg is in development mode. Whether this carries over after the merge into WordPress core needs to be verified.

There is a bug in Gutenberg regarding the display of the privacy notice tool. @desrosj has noted this as Gutenberg ticket 10448.

Gutenberg utilizes the Noto Serif Google Font for supported locales. @garrett-eclipse asks whether a font replacement should be proposed for the 5.0 merge, or whether the suggested privacy policy content should be updated to include Google Fonts verbiage.

The emojis in Gutenberg load from and need further review. @garrett-eclipse seeks clarification on whether emojis are part of core and therefore covered by the existing privacy notice language.

Regarding embed blocks, @garrett-eclipse suggests that how core handles them from a privacy standpoint should follow whatever is done for embeds in general. He suggests it would be useful to propose to Gutenberg/core the feasibility of creating a “privacy flag” on blocks which could flag users about potential privacy concerns, and/or flagging admins that blocks with potential privacy ramifications have been added on their site.

BuddyPress and Privacy Reviews

@garrett-eclipse and @jjj have arranged to conduct a basic privacy review of BuddyPress.

This led to a discussion about privacy reviews being a service which the team could offer, akin to theme, plugin, or accessibility reviews. All were in agreement that the parameters and deliverables of these reviews would need further discussion. All in attendance also agreed on the need to make absolutely clear that privacy reviews would not be legal advice, nor could they be carried out in regards to achieving compliance with any specific privacy law. Rather, the reviews would focus on general issues of data collection, flows, retention, and sharing. Any action items which reviews might identify would be the developer’s responsibility to address, and not the core-privacy team.

@allendav suggested that “needs-privacy-review” could be added as a tag in Trac for patches and tickets.

@garrett-eclipse and @allendav will document the processes they have used in their Gutenberg and BuddyPress evaluations, with a view towards using these steps as the basis of a potential privacy review checklist for the handbook.

Component Documentation Review

@allendav wrote handbook documentation as part of the V1 roadmap earlier in the year. All in attendance agreed it would be good to review the handbook for new material that could be added, and to see if additional audiences could be accommodated. @allendav and @riankinney will review the existing documentation and report back with suggestions. Documentation from other teams, including design and accessibility, provide good examples to follow.

@garrett-eclipse suggested that the Privacy by Design standards used by core-privacy could be more widely adopted across the WordPress project, and more visible documentation could help to promote this.

Team Issues

A healthy and constructive discussion was had on whether the core-privacy team should continue to identify as a core component or should seek to additionally become a team. The team agreed to consult with @chanthaboune on what options are available within the team and component structure.

Group Meta Issues

Last week @desrosj circulated a Doodle poll to find a better time for weekly office hours. From the suggestions provided there, he has launched a second Doodle poll narrowing the selection down to the four most popular answers. Please provide your two best choices. The Doodle poll will appear in your local time zone, not in UTC.

@allendav has been looking into more privacy-conscious collaboration tools and reports he is not happy with the UX of Etherpad.

Sarah Gooding interviewed @idea15 for an article about the team on WP Tavern. @riankinney is doing a privacy podcast with WPBob later this month.

The next core-privacy office hours is Wednesday, October 24, 2018 at 1500 UTC. A new office hours time will be decided in this meeting.


Core-privacy agenda – 17 October 2018

This is the agenda for the weekly #core-privacy meeting on Wednesday 17 October 2018 at 1500 UTC:

Roadmap issues

Team issues

  • Group definition: Are we a core component? A component? A team? @idea15
  • Group lack of visibility and consideration: how do we get more of it within and outside the project regardless of how we are categorised? @idea15

Group meta issues


What’s new in core-privacy

Below is a summary of the discussion from this week’s #core-privacy chat. You can read the chat in its entirety in Slack. This summary highlights current work and also provides a view into how this relatively new team is working together to further privacy awareness following the success of its V1 GDPR-specific focus.

Ticket milestone changes

As a result of 4.9.9 being removed from the schedule in favor of a Gutenberg only 5.0 release, 25 core-privacy tickets scheduled for 4.9.9 have been punted to either 5.0.1, 5.1, or Future Release. These included some which were already committed to trunk and backported to 4.9.9, as well as some marked commit which will not be shipped with 5.0. Each ticket will be reviewed and evaluated for release with either 5.0.1 or 5.1. Each ticket can be re-milestoned when the scopes and timelines of these releases become more clear.

Impacted tickets include #44038, #44044, #44051, #44081, #44084, #44135, #44175, #44179, #44267, #44314, #44550, #44621, #44644, #44669, #44674, #44677, #44707, #44723, #44761, #44822, #44833, #44901, #43438, #44233, and #44236.

The component’s focus until post-Gutenberg will shift to the (currently) 31 bug tickets, with a goal of marking at least 75% of them as ready for commit.

@allendav and @desrosj will also use the feature and enhancement freeze to address #43895, which aims to properly organize the privacy code introduced in 4.9.6 within the codebase.

A full list of privacy tickets can be found in Trac.

Bug scrubs are led by @desrosj every Monday. The next one will be held October 15, 2018 at 15:00 UTC in the #core-privacy room on Slack.

Future major release

There was agreement that advocating for Privacy to be a focus for a future major release (possibly 5.2) would be very helpful to land the features outlined in the V2 roadmap. The timing of two pieces of legislation of particular interest would potentially coincide with that release schedule, allowing those features to be shipped prior to the effective dates.


The V2 roadmap moves beyond the enhancements and fixes to the V1 GDPR privacy tools to address general areas of privacy and data protection outside legal requirements. Its scope includes:

  • Core privacy features
    • Gravatar privacy controls
    • Embed privacy controls
  • Plugin privacy
    • For administrators
    • For developers
  • Consent and logging
  • WP-CLI support
  • Multisite support

This week, those in attendance agreed to add two upcoming privacy issues within legal requirements – the US California Consumer Privacy Act (CCPA), and the EU ePrivacy Directive overhaul – to the roadmap. It is anticipated that these two pieces of privacy legislation will create the most obligations for WordPress site administrators in 2019. Team members will continue to monitor each law carefully. Once the specific requirements are announced by each respective government, a discussion of what functionality may need to be created to allow site administrators to meet their requirements well ahead of compliance deadlines will be had.

@idea15 is the lead for monitoring and evaluation of privacy legislation. @idea15 and @riankinney are working on an analysis of CCPA.

They are also monitoring other privacy legislation, including individual US state requirements as well as that of countries like Brazil, to anticipate possible future work.

Gutenberg review

@allendav is reviewing Gutenberg for any potential privacy issues stemming from CDNs, telemetry, or other issues, and will document his findings. Please make him aware of any concerns. He also welcomes privacy evaluations of Gutenberg from non-Automattic testers for transparency’s sake.

#45057 is currently the only Gutenberg blocker from a Privacy standpoint.

Cross-platform privacy working group

At Drupal Europe, @idea15 and Chris Teitzel from the Drupal core privacy team gained enthusiastic support from Dries Buytaert for a proposed cross-platform privacy working group. This group would create a forum for the core privacy teams from all major open source CMS projects (WordPress, Drupal, Joomla, Typo3, etc), to engage, share resources, compare experiences, and periodically meet in person to discuss privacy issues on the social, legal, and code levels. The group, which would be run through the Drupal community structure, may receive some funding. @idea15 will update the WordPress core privacy team in the next fortnight with news.

Group meta issues

  • Our current weekly office hours time of 1500 UTC on Wednesdays does not work for most participants. If you are interested in attending the weekly office hour meetings, please fill out this Doodle poll to identify a better time.
  • The component will be more diligent about posting agendas and meeting summaries on the Make core blog. New contributors are encouraged to volunteer, as this is a great way to get involved. @desrosj, @idea15, and @allendav will ensure these are posted when there are no volunteers for that week.
  • The team will discuss and choose team reps, in response to a discussion during the weekly Core dev chat of whether the core-privacy group is a team in addition to a component and focus.
  • @allendav will research more privacy-conscious document and collaboration tools outside Google docs.

Next Meeting

The next office hours will be held on October 17, 2018 at 15:00 UTC in the #core-privacy room on Slack.


JavaScript Chat Summary – July 3rd

Below is a summary of the discussion from this week’s JavaScript chat (agenda, Slack transcript).

Participants: @abdullahramzan, @adamsilverstein, @aduth, @afercia, @atimmer, @bpayton, @euthelup, @gziolo, @herregroen, @lonelyvegan, Jorge Costa, @omarreiss, @nerrad, @netweb, @pento, @sharaz, @schlessera.

Have a topic for discussion for the next meeting? Leave a suggested edit on next week’s agenda.

Deprecation Strategy

(Continued from last week’s discussion)

Problem: How can we introduce breaking changes necessary for user benefit without sacrificing a commitment to backward compatibility?

A deprecation strategy proposal has been discussed. Some highlights:

  • Proposal to Include a link to the specific documentation surrounding a deprecation (similar to React).
  • Console logging turns out to be not entirely successful on its own based on the experience from Gutenberg.
  • Feedback collected should be integrated into the UI, ex. Admin bar, Updates screen.
  • For those plugins that are using a recommended set of core build tools, issues could be surfaced there.

Action items:

  • Chat to #meta about logging all deprecations.
  • Discuss Admin bar notifications integration with @johnbillion, who authored Query Monitor plugin.
  • Logging to is also something that should be discussed with the #core-privacy team to make sure we start out in a compliant fashion.

Discussion is going to be continued next week.

Sunsetting the Packages Repository

Last week it was decided in our meeting to merge WordPress/packages repository to the WordPress/gutenberg repository. There is an open pull request at which is almost ready to land. We are waiting for Gutenberg 3.2 release to ensure it doesn’t interfere with the development cycle.

Next steps:

  • Fix the problematic test suite which started to fail on Travis after it was moved to Gutenberg.
  • Merge in the latest changes added in Gutenberg.
  • Test, review and deploy!
  • Ensure all opened issues, PRs , and missing docs are moved over to Gutenberg repository. @netweb started it already.

Core CSS

@omarreiss gave
update on core CSS reorganization. Mostly the same as the JS effort, but smaller scope. The current idea is to unify the CSS in
a `src/styles` directory with a ` css` and a `sass` directory. We discussed the following:

  • Is Sass the right path forward or should we move closer to native CSS with something like PostCSS?
  • There were previous discussions with @helen in the past on further refactoring CSS to use native CSS with PostCSS rather than Sass/SCSS.
  • How do we deal with styles reuse in a components era? There are similar ongoing efforts in Gutenberg started by @youknowriad in

Code Style

There have been new proposals with regards to code styling:


  • Let’s move forward with quotes exception following the related PHP standards.
  • @aduth is going to add more explicit rules around acronyms at start of variable name and leave the rest as initially proposed.

Dev setup

It’s been requested that two core Trac tickets receive approval:

  1. Make sure all JS globals are explicitly assigned to the window:
  2. Move all JS build config to Webpack:

@netweb volunteered to review item (2). It was also noted that (2) depends on (1).

WordPress Privacy Chat Agenda – June 20

Agenda proposal:

  • Stats (Trac tickets)
  • Roadmap
  • Feedback from WCEU Contributor day and the workshop
  • Open discussion

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

WordPress Privacy Chat Agenda – June 06

Agenda proposal:

  • Welcome to new contributors
  • Info: Name change: slack channel, GitHub repository
  • Stats: Trac tickets stats
  • Roadmap
  • Open discussion

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

Dev Chat Summary: May 30th (4.9.7 week 2)

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

4.9.7 planning

  • No pressing need for quick 4.9.7 release, so aiming for ~6-8 week release cycle for 4.9.7
  • Leads nominated so far: @sergeybiryukov able to help as deputy (e.g., committing, backporting); @danieltj, @desrosj, and @tristangemus open to help contribute during 4.9.7
  • Please comment on this post, ping @jeffpaul, or comment during the next dev chat for nominations (self or otherwise) for release leads on 4.9.7

Updates from focus leads and component maintainers

  • The PHP team posted a summary from their meeting last week covering the “Upgrade PHP” page and possible Gutenberg blocks. Please join them this coming Monday, June 4th at 15:00 UTC in #core-php
  • The GDPR Compliance team met earlier today and of note will be changing the Slack channel and post tags to Core Privacy this Friday, June 1st. Please join them next Wednesday, June 6th at 15:00 UTC in #core-privacy

Guidelines for fixing coding standard violations

  • Now that r42343 has landed, Core is accepting patches to fix coding standards (CS) violations. The meeting attendees agreed on the following guidelines:
    • Patches for any CS fixes are welcome, as long as they’re not so extensive that it would require refreshing an unreasonable amount of regular patches.
    • In order to avoid wasting time, patches for violations which cannot be automatically fixed by `phpcbf` should be given preference over ones that can be automatically fixed.
    • Regardless of many files are touched in a CS patch, the corresponding commits should be limited to fixing a single file in each commit.
    • CS patches should be treated just like any other patch, and reviewed critically before being committed. That also applies to any changes made by `phpcbf`.
    • Commits for new features, bug fixes, and other “logic” changes should not include unrelated CS fixes. Coding standards fixes should be done in a separate commit. If a line is already being changed to fix a bug, etc, then it should have CS violations fixed at the same time. If fixing the violation for that line would introduce changes beyond that line, though, then the CS fixes should be done in a separate commit.
  • Does anyone strongly object to those, before they’re added to Handbook?

General announcements

Next meeting

The next meeting will take place on June 6, 2018 at 20:00 UTC / June 6, 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-php, #core-privacy, #dev-chat, #gdpr-compliance, #summary, #wpcs

GDPR Compliance Chat Agenda – May 30

Note: GDPR Compliance will be renamed to Core Privacy on June 1. The slack channel and post tags will be adapted accordingly.

Agenda proposal:

  • Info: Name change
  • Stats: Trac tickets stats
  • Info: Weekly bug scrub
  • Roadmap v2, v3
  • Open discussion

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