Javascript Chat Summary – December 4, 2018

Below is a summary of the discussion from this week’s JavaScript chat (agendaSlack Transcript)

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

Agenda: Holiday / WCUS scheduling

Slack Conversation

We agreed to cancel the #core-js meetings for December 11th (post-WCUS travel), December 25th (Christmas), and January 1st (New year). @aduth posted a cancellation notice here: https://make.wordpress.org/core/2018/12/04/javascript-weekly-chats-wordcamp-us-holiday-scheduling/

Agenda: Linting

Slack Conversation

A PR which extracts Gutenberg’s ESlint config to its own package by @gziolo has been merged. It’s set to be published to NPM as @wordpress/eslint-config. Publication is currently blocked by the 5.0 RC freeze, but is expected to land around contributor day together with a post outlining revisions to the JavaScript coding standards prepared by @aduth

We also discussed how to manage custom eslint rules. Some linting rules might not be useful outside of the context of WordPress core or Gutenberg. We decided for now to go the same path as the Jest eslint package. For the time being we will have one package with multiple configs, which will allow consumers to select the configs they need. 

Agenda: 5.0 Script Changes

Slack Conversation

With WordPress 5.0, a few vendor scripts (like lodash) are being included in core. For these scripts in particular, there is a chance for conflict if a plugin or theme registers their own copy of the dependency with the same un-prefixed name. There is a greater likelihood if there is a large version mismatch between the registered scripts.

Different approaches to prevent this were discussed. @aduth is working on a devnote to help integrators prevent these kinds of conflicts from happening.

#javascript, #meeting-notes

Javascript Chat Summary – November 27, 2018

Below is a summary 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: WordCamp US

Slack Conversation

The question was posed “Who is going to WordCamp US” followed up by some shared info about what folks from the js team are doing at contributor day:

  • @omarreiss along with @atimmer are working on docs parsing for devhub.
  • @gziolo is getting into e2e setup exposure for core (related: https://github.com/WordPress/gutenberg/issues/12313)
  • @aduth suggested it’d be nice if there could also be some work around automating as much as can around things like package/bumps dependency management (or at least talking that through).
  • @jorgefilipecosta mentioned there will be a table dedicated to Gutenberg and everyone is welcome.  Some “good first issues” will be prepped for first-time contributors and there will also be some higher level discussions around server-side awareness of blocks and the blocks options mechanism.
  • @adamsilverstein will be co-leading the Core group, with mention of Javascript work in the description.
  • There will also be a group focused on tests where the test discussions/work may fit or at least benefit from some cross collaboration between tables.

Lot’s of ways to get involved at WordCamp!

Open Floor: Consolidation of our ESLint configurations

Slack Conversation|Related Github Issue

Summary: Consolidating various eslint configurations and extracting them into their own package.

This was originally blocked by introducing the remaining standards changes as a proposal via Make/Core (see https://make.wordpress.org/core/2018/7/25/javascript-chat-summary-july-24th/)

Actions:

  • publish the new @wordpress/eslint-config package.
  • shortly after, or around the same time, publish a make/core post outlining proposed changes to the WordPress javascript standards and references the new published package as the codified representation of them.  
  • the post invites feedback/comments on the proposed changes and responses will help tailor how the package is iterated on and also what gets updated in the official javascript standards documentation for WordPress after a week of comments.

#javascript

Dev Chat Summary: November 21st (5.0 Week 8)

This post summarizes the dev chat meeting from November 21st (Slack archive).

5.0 Planning and Updates

  • Gutenberg 4.4 and WordPress 5.0-beta5 shipped, including updates to the block editor, PHP 7.3 support, and Twenty Nineteen.
  • The 5.0 / Gutenberg team continued their daily updates to Make/Core, noting PRs and issues remaining, as well as recent and upcoming plugin releases (see 11/16, 11/19, 11/20).
  • There are a few pending tasks in Trac needing attention, which meant release candidate didn’t happen yet. On the Gutenberg side, milestones are clear after 4.5.1 was released early in the day. Anyone who can commit or review, it would be great to get your attention on those remaining Trac tickets as a priority. Find out more in the post just released today.
  • The documentation reorganisation is merged and new documentation is being added. There are a couple of excellent outlines available for users and site maintainers as well as designers and developers.

Focus and Component Updates

  • The PHP team shared last week’s meeting recap with notes on Servehappy, adding support for PHP version requirements to themes, and beginnings of coordination with the Theme Review team.
  • The JavaScript team shared this week’s meeting recap with notes on correcting package global names and npm packages publishing workflow.
  • The Privacy team met earlier today, so only their agenda is currently available that covers 5.0 testing/patches, 3rd party code on wp.org footers, mobile app permissions and tracking, Google Fonts in Gutenberg, and Google reCAPTCHA 3.0. A full recap will be posted soon.

Announcements and Open Floor

  • The date of the release candidate and the WordPress 5.0 release was discussed. The primary goal is to finish the RC, then decide upon an appropriate release date.
  • @aaroncampbell asked for volunteers to help onboard people, and guide them to first bugs for non-Gutenberg work at WCUS. Please reach out to him if you’re able to help.

Next Meeting

The next meeting will take place on Wednesday, November 28 21: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 the upcoming agenda post so that we can take them into account.

#5-0, #core, #dev-chat, #summary

JavaScript chat summary – November 20th

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

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

We tried to keep the meeting succinct as many people are pushing out a Gutenberg release.

Correcting Package Global Names

Relevant context in a previous Slack discussion. Question: Should we “deprecate” wp.escapeHtml to wp.escapeHTMLwp.tokenList to wp.TokenList?

There was a bit of a back and forth whether this should be something that is addressed now. At the end we concluded to add this to the list to address in a 5.0.x release.

Npm packages publishing workflow

From last week, we discussed this very briefly to keep it in our mind space. Link to the relevant issue on the Lerna repository.

#chats, #javascript, #meeting-notes

JavaScript Chat Summary – November 13th

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

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

Npm packages publishing workflow

Discussion: When working on the WordPress 5.0 release cycle we noticed that our workflow for publishing packages to npm isn’t ideal. Using Lerna helps a lot but it doesn’t solve all issues. We should work towards improving the workflow and address the items listed in this GitHub issue.

Considerations:

  • At the moment we defer to Lerna performing version increments for all packages. We only express our intent for the change inside of the corresponding changelog files when working on PRs. The biggest downside of this approach is that we need to scan all existing changelog files during publishing and re-apply manually the proper version bump for each package. It would be a nice improvement if we could update both changelog and package.json with a new version at the same time when PR gets merged. Lerna could use that and skip the step to ask what version should be applied.
  • In the past, we had publish failures caused by 2FA timeout where we had more packages to publish than it could be handled in 30 seconds. There is an open issue where improved 2FA Support is discussed. However, 2FA isn’t the only thing that could go wrong in the process so it would be nice to see publish re-tries in the flow and prompts for new OTP token when the current one expires.
  • It would be nice to see is a way to verify if published packages are healthy. As mentioned above, we had 2 cases where 2FA timeout caused some issues which led to having broken package.json files on npm. It might happen again, so we should be at least able to detect it immediately and take proper actions.

Action Items:

  • Share what we discussed today with Lerna team in RFC: Improving lerna publish issue in their repository and figure out how we can work together to improve our workflow.
  • Continue discussion next week.

i18n Core Merge Update

We have an update on the i18n front in that support for JavaScript localization has been committed for WordPress 5.0 and support added to translate.wordpress.org. You can read more at the following links:

The major functionality has launched and only bug fixes are likely to remain. It’s safe to say that plugin and theme support can be added after 5.0 release.

Open discussion

Question: @nerrad asked whether the @wordpress package namespace on npm is intended for only things used specifically by the WordPress team or project. Are they also things we think contribute to the larger JavaScript ecosystem that might use WordPress?

@aduth shared that we should be spending resources most toward things which are actively used in the development of WordPress. If someone wants to contribute enhancements or fixes, that on its own would be fine. We also don’t need to pull projects no longer used.

It was also discussed that the deprecation feature offered by npm should work well for cases when we know up front that a package won’t be maintained anymore.

JavaScript Chat Summary – November 6th

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

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

Node LTS 10.13.0

With the tagging of a new Node LTS 10.13.0 last week (from 8.x), both Gutenberg and Core builds are now running the latest version.

Data Module Generic Store API

refactoring of the data module has been merged, and it now exposes a new optional lower-level API for non-Redux stores, or more personalized instances of a Redux store.

Refer to the documentation for more information.

JavaScript Future Backwards Compatibility (and React)

Discussion: How can WordPress continue its commitment to backwards-compatibility while also not perpetually lagging behind the current version of dependencies (specifically, but not exclusively React).

Considerations:

  • Explore what it could look like to version WordPress scripts
  • Targeting the abstraction (wp.element) an intentional point in ensuring consistent version use.
  • Provide and/or surface codemods if it comes to the point of being forced to introduce a breaking change (Facebook does similarly with React)
  • Gutenberg’s deprecation pattern is not something which would necessarily continue post-5.0, but could serve as precedent for a future deprecation model

Action Items:

  • Compile a document which outlines expectations for a plugin author to anticipate and account for future compatibility, how and when a breaking change would be introduced

Implementing End-to-End Tests in Core

Continuation of discussion from last week.

Problem: How can Gutenberg’s end-to-end test suite be brought into the core development workflow?

Considerations:

  • Not blocking for a 5.0 release
  • Tracked at #45165
  • Having an end-to-end testing solution is useful for more than just the editor, and useful for more than just core development

Solutions:

Make some core part of the end-to-end solution available in @wordpress/scripts.

i18n Core Merge Update

@omarreiss shared the following update:

WP-CLI: Make sure wp i18n CLI command includes JavaScript translations when generating potfiles. [Done] Relevant PRs: https://github.com/wp-cli/i18n-command/pulls?q=is%3Apr+is%3Aclosed+author%3Aherregroen .
Meta: generate translations on translate.wordpress.org for core, themes and plugins. [MVP Done] Ticket: https://meta.trac.wordpress.org/ticket/3748
Meta: generate and serve JS language packs from translate.wordpress.org for core, themes and plugins. [Has patch] Ticket: https://meta.trac.wordpress.org/ticket/3876.
Core: Logic to load JS translations. [Done] Ticket: https://core.trac.wordpress.org/ticket/45103
Core: API to register JS translations for a script. Needs meta side of things to be finished. [Has patch] Ticket: https://core.trac.wordpress.org/ticket/45161
Make: Publish an update and a devnote on how the JS translations work. [todo @omarreiss / @herregroen]

@herregroen shares that for most plugin authors who host their plugins through the plugin repository, the change in workflow should be a matter of using wp_set_script_translations in place of where traditionally one would use wp_localize_script.

Reflecting on @wordpress/hooks

Prompt: As a retrospective of how wp.hooks has been used in the development of core, what feedback do developers have to share?

Feedback:

  • @youknowriad : “In general I’m thinking JavaScript is not a good fit for our hooks because JavaScript is a real time UI not like PHP where the flow is linear. The UI has to be Reactive and it’s very hard to achieve with hooks without pitfalls.”
  • @omarreiss : “I think it might also not be the pattern we want to teach the WP community.”
  • @herregroen : “I would give some thought to deprecating before release to send a clear message going forward. I think it would be confusing to have this familiar API and then never expand it and soon after start deprecating it.”
  • @aduth : “My general experience with them is that they’re not completely avoidable, but in the majority of cases I’ve seen them proposed, it’s been the wrong way to go about a problem with some serious non-obvious consequences and I’ve thus looked to them as a “footgun” (a tempting tool too easy to use wrongly)”
  • @adamsilverstein : “i’ve mainly tried using the withFilters HOC which seemed to work well, i’m not really sure where else hooks have been used in Gutenberg. I agree they can easily be misused and better approaches are often available.”
  • @schlessera : “It’s a procedural pattern that quickly breaks down once you go past procedural code, even in PHP.”

Takeaways:

There’s some general consensus that the pattern is not a good fit for how Gutenberg has been architected, and it’s assumed that this will apply as generally true for core features written in a similarly JavaScript-oriented approach.

It’s also true that there is usage of JavaScript hooks within Gutenberg for which a better alternative has surfaced. Thus, they will likely remain a tool, albeit one we should consider to avoid as much as possible, and limit exposure and advocation.

Action Items:

Consider a communication plan for the role of hooks (future agenda item).

#javascript

Media Meeting Recap – October 25

Overview

This post is a summary of the latest weekly Media component meeting, which took place in the #core-media Slack channel, on Thursday, October 25, 2018 at 18:00 UTC The purpose of these meetings are to move priority tasks forward, provide feedback on issues of interest, and review media focused issues. Due to a conflict in bug scrub scheduling, we did not have a Media meeting last week. Lets get into it!

Attendees:
@joemcgill @mikeschroder @desrosj @antpb

Transcript: Read on Slack

WordPress 5.0

The meeting focused entirely on the WordPress 5.0 milestone Gutenberg Issues. There are 20 remaining Media issues in the 5.0 milestone. There are 8 labeled backwards-compatibility:

Let’s get right into the issues discussed! 

3672 “upload_files” capability and Image relative blocks

 https://github.com/WordPress/gutenberg/pull/9301 brings this very close to completion. @joemcgill mentioned “That PR is pretty close. My only problem with it is that there was no way to allow a contributor to open the dialogue even if they couldn’t upload media.” Which we don’t currently support, but it’s easier to override outside of Gutenberg. I think for 5.0, the PR as it stands is probably ok, but then we should quickly create a ticket that adds capabilities that distinguish uploading files from reading/inserting files”


 1451 Gallery: figure out way to fallback to shortcode

 5972 Gallery Block doesn’t apply the ‘post_gallery’ filter, causing incompatibility with WP Gallery Custom Links

The two above issues will be solved if we move forward on a classic-gallery block that allows a fallback to the gallery shortcode function. @antpb has built a POC classic-gallery block that can be tested here: https://github.com/antpb/gutenberg/tree/add/classic-gallery 

Note: there are some pending CSS issues that @antpb has to work through but largely the block reaches parity with the < 5.0 implementation. The existing gallery shortcode options are exposed in the block inspector. The classic-gallery-block is not a solid decision yet, just an option worth the proof of concept.

Thinking here is that we can allow a transform to ensure that the gallery shortcode is hit which also allows the post_gallery filter to be respected.

@joemcgill mentioned “I would much rather a theme add theme support for Gutenberg galleries or something.” which is currently one option going forward on this issue. This has historically been done. An example shared was: https://make.wordpress.org/core/2014/04/15/html5-galleries-captions-in-wordpress-3-9/

We have closed 5972 to keep focus an conversation moving in 1451


 4612 Media Library doesn’t update after dragging image onto Image block

@antpb re-opened a PR that fixes the issue and there were some recommendations to it that have been revised. PR is currently awaiting another review. Super close.


5936 Avoid race conditions between media upload and autosave

 8935 Issues when uploading images to a Gallery block: The response is not a valid JSON response.

We have an issue with race conditions and also with large image uploads that take a while. 8935 has clear reproduction steps on the gallery large image issues.


 1520 Images alt attribute in an editing context

This one is very close to completion. @antpb has made the final requested changes to only store default alt text in the editing context. Should be wrapped up soon.


 <img/> tags missing attribute filter 2258

@joemcgill did some research around this since the meeting as it was discussed that this was a critical issue needing investigation. We’ve closed this issue in favor the other filter related issues already open. Joe’s discovery work there is worth the read Also mentioned by Joe in the meeting: “I do think we might want to deprecate that filter after 5.0, but we should definitely support it.”


 6824 Video Block doesn’t work when inserting YouTube URL

Users will likely expect to be able to paste a youtube/vimeo/etc. video into the video block. @antpb asked: “how do y’all feel about it? The scope of this issue is not just youtube. Should the video block know what to do with all of our embed types?” @joemcgill responded “I wonder if we could be smart and auto-switch blocks based on some kind of URL regex? Or at least provide a helpful error message that guides people to the correct block.”


 7504 Consider feature parity for “Image Details” TinyMCE functionality

@mikeschroder mentioned that this issue needs to be split out due to https://github.com/WordPress/gutenberg/pull/7771 

@mikeschroder mentioned “I think it’s missing a PR, and a decision on whether title should be included. The other thing, that isn’t addressed is attachment_fields_to_edit Which should definitely have its own ticket. Mike is continuing to work to bring an existing PR up to date. 


Next Meeting

The next #core-media meeting is set for Thursday, November 1, 2018 at 20:00 UTC See you there!

#core-media, #media, #summary

JavaScript Chat Summary – October 30th

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

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

Meeting time adjustment

Due to DST and starting next week, the #core-js meeting time will be moved to 14h UTC.

Node 10.x LTS

A new LTS version of Node.JS has been released. As agreed upon on previous meetings, WordPress is going to follow the LTS schedule of Node.JS which means, we’re going to start using this new LTS version in local environments (Gutenberg and WordPress).

The systems team has been also notified to upgrade the WP.org servers to Node 10.13 LTS.

E2E Tests in Core

End 2 End tests are automatic tests simulating user interactions using a browser in a production environment. Gutenberg uses Google Puppeteer and a docker environment to run a suite of various e2e tests that include:

  • Creating and publish content,
  • Writing Flow,
  • Accessibility tests,
  • Extensibility tests.

We discussed during the meeting approaches to make the E2E Test setup and the test suite available for:

  • Plugin Authors:  to setup their own e2e tests,
  • Core: To validate that the Gutenberg integration is working properly and allow other parts of WordPress Core to be tested using this setup. 

Action items

  • Explore making the e2e test setup available as an npm package. cc @gziolo
  • Explore making a package containing the Gutenberg e2e test suite to be able to run it in Core.

Shorter-term, we discussed the possibility of duplicating the tests in Core to validate the Gutenberg integration and package updates. 

If you have some availability and would like to help with any of these items, please let us know in the comments.

#javascript

Javascript Chat Summary – October 23, 2018

Below is a summary of the discussion from this week’s JavaScript chat (agendaSlack Transcript)

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

Agenda: Should wp.hooks support the special all hook?

Slack Conversation

In Gutenberg#8602 it is raised if we should add support for an all action in wp.hooks in order to match feature parity with the current PHP hooks system in WordPress core. While there were no real objections raised in the chat, pretty much everyone present agreed with this comment:

If it is primarily intended for debugging, then it might be worth exploring optimizations to avoid any impact in typical usage, e.g. monkey-patching runHooks when an all hook is added.

@aduth

Actions

  • No interest was expressed in the issue. If anyone wants to take it on, there wouldn’t be any objections either.

Agenda: Ways to optimize the package updating process

Slack Conversation

The process for updating packages needs to be optimized further. Right now any fix on a package has to follows the cumbersome flow of Gutenberg PR -> lerna release -> core ticket -> update package.json -> commit. We need to make this smoother.

This problem would probably not exist once everything is merged into a single monorepo hosted on git. But that doesn’t seem feasible just yet. Could we maybe mimic the advantage of having a monorepo a bit by getting more tooling into WordPress core and build straight from Github source? That would at least decouple publication of packages from being able to consume their changes in WordPress core development. 

It was raised by @gziolo that installing Gutenberg straight from Github with npm is not an option because Gutenberg consumes local packages which can’t be resolved by npm. The solution proposed is to take a similar approach to how Gutenberg packages are updated for Drupal.

This is done with an install script that simply clones Gutenberg into node_modules and builds the scripts in Gutenberg itself. While not a very elegant solution, this could work and drastically improve the process of keeping the packages updated.

Actions

  • @atimmer will work on a proof of concept.

Open floor: JS i18n

Slack Conversation

Good progress is being made on JavaScript language packs. 🎉 @herregroen is working together closely with @nerrad, @swissspidy and @ocean90 to land this. There seems to be a great deal of consensus and the work is nearing completion.

#corejs, #javascript

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 https://gutenstats.blog, @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 s.w.org 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

#privacy