Tag Archives: core-js

Omar Reiss 9:05 pm on February 10, 2019
Tags: core-js, ,   

JavaScript chat summary, February 5th, 2019

Below is a summary of the discussion from last week’s JavaScript chat (agenda, Slack Transcript) Please excuse the delay!

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

Agenda: Changelogs

Slack Conversation

In a previous discussion a need surfaced to improve Semver for JS packages and better understand the changes we are syncing into WordPress core when we update the JS packages. For this, better changelogs are needed. @aduth has been working on a PR to enforce better changelog management. It explores adding a pre-commit githook which verifies that the contents of the pending commit include a CHANGELOG.md revision if applicable.

Some concerns were raised about the potential unwanted friction a githook could give and false positives that could occur when ie. committing typo fixes. A possible alternative is to make the check part of the Travis build for PR’s. On the other hand, the direct feedback gotten through the githook contains higher educational value and minimizes loss of context.

We agreed the current githook proposal was worth exploring further in order to see if false positives can be prevented.

Agenda: Code owners

Slack Conversation

A pull request which adds an initial implementation of a CODEOWNERS file in Gutenberg was merged.

You can use a CODEOWNERS file to define individuals or teams that are responsible for code in a repository.

Github Help

Contributors are invited to PR the file if they feel they would like to be added as a code owner for specific paths in the Gutenberg repository. When accepted, they will receive pull request notifications and review requests for these parts of the codebase.

The main goal is to alleviate some review pressure for the Gutenberg team and help distribute notifications and help requests better over more contributors. It was argued it could be good to have some guidelines for approving / merging PRs in order to allow new contributors and code owners to review with more confidence. The use is expected to further evolve and be evaluated in the coming weeks.

Agenda: Registry selectors

Slack Conversation

For a while now we’ve had the option to register multiple stores across multiple registries using the core/data package. But how can we create selectors which derive data across multiple stores / registries? A PR to tackle selecting data over multiple stores has been created by @youknowriad. Input and feedback is requested.

An effort that depends on this is a PR which tries to make the editor module more generic so it can be reused outside of WordPress. We need to be able to respect backwards-compatibility while moving selectors and action dispatchers from one module to another. See also: https://github.com/WordPress/gutenberg/pull/13088

Open floor: React hooks

Slack Conversation

React hooks has been included in the latest release of React. There is a PR on Gutenberg which explores the possible advantages of this new API: https://github.com/WordPress/gutenberg/pull/11161. Since Gutenberg relies heavily on React, it could be worthwile checking out the API and the ways it could be leveraged in Gutenberg.

#core-js, #javascript, #meeting-notes

Darren Ethier (nerrad) 3:47 pm on January 29, 2019
Tags: core-js,   

Javascript Chat Summary – January 29, 2019

Below is a 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: Unstable APIs

Slack Conversation

There was a conversation recently on Github where it became evident that marking an API as unstable is not sufficient enough in its own right to scare people away from using them (and subsequently being frustrated that they’re not documented).

This was a lively discussion around whether there are programmatic ways to make it harder for people to use things marked __unstable .

Due to the fact there aren’t a lot of occurrences of __unstable in the code currently, the general consensus seems to be that if people are using __unstable that is a risk they are taking and there shouldn’t be worry about removing it because it’s purpose is clear.

However, this could be revisited in the future if we see usage pick up and ideas mentioned in the meeting may be explored further then.

So readers, TAKE NOTE – use anything prefixed with __unstable at your own risk. Expect your code to break in the future if you are implementing it!

Agenda: New ESLint Rule

Slack Conversation|Related Github Issue

A new rule was introduced, no-unused-vars-before-return

Agenda: Yarn future (fyi)

Slack Conversation | Related Yarn Github Issue | Related Earlier Slack Discussion

Some discussion around some potential benefits this roadmap could have should yarn be adopted for WordPress builds in the future:

  • Yarn as an API (which could open the door to controlling some things from a GUI). This could allow for building easier developer tools.
  • Yarn as a package manager platform – which means there could potentially be one package manager for both npm and packagist.
  • Improvements to mono-repo management (in terms of managing both js and php packages)

This was mostly presented just to get on everyone’s radar. There’s nothing actionable at the moment.

As an aside: if you become aware of interesting developments in the javascript world, please do include them as fyi’s in #core-js meeting agendas!

Agenda: Package alignment with core

Slack Conversation | Related Make Post

@desrosj presented how looking at this trac ticket got him thinking about how we can better align package versions with Core to prevent issues like what popped up there.

Summary of what could become a proposal:

  • In simplest form, change version constraints in the package.json
  • When a major WordPress version is released (say 5.1), the versions of each package become restricted to only minor and patch updates to @wordpress/* packages and dependencies. This allows someone to run npm update when preparing a WP minor release (5.1.1) for beta.
  • When a new major WordPress version is prepared, a new major version of the Gutenberg packages would be released (if necessary), and WP core would be updated to use that new version. This next WP version (5.2) would be locked to that next version’s patch and minor updates only.
  • From a process standpoint, this would require the Gutenberg branches to somewhat match core’s. There would need to be a 5.1 branch after that is released. Instead of cherry picking changes by using package versions, we could only back port the appropriate changes to that branch and publish the X.X or X.X.X versions of those NPM packages

The difference between what is currently being done and what is being proposed is that whenever there is a major release of WordPress, all versions of packages will be bumped with major or minor (as opposed to patch).

One reason this was brought up is concern for how security patches etc will be back-ported to earlier WordPress versions in the future

Next Steps

  • Tighten up semver in @wordpress/* packages which means enforcing proper usage of CHANGELOG.md and properly differentiating between minors and patches. (No owner currently)
  • Explore more automation of the package management/updates in WordPress core (No owner currently)
  • This does need revisited in future meetings. Work should be done on identifying clearly the problems needing solved.

#javascript

Omar Reiss 10:50 am on January 23, 2019
Tags: core-js, , ,   

JavaScript chat summary, January 22nd, 2019

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: NPM Scripts

Slack Conversation

A few new commands have been proposed for addition to the @wordpress/scripts module:

  • build and start: https://github.com/WordPress/gutenberg/pull/12837
  • format: https://github.com/WordPress/gutenberg/pull/13394

The discussion around build and start focused mostly on the question how to approach default configuration for plugins and themes. We’re considering to extract parts of the Webpack config as npm package to simplify setup for plugin developers. This would also allow to provide a default config for @wordpress/scripts and proposed scripts. To provide flexibility, it was raised that an eventual Webpack config package could have 3 types of exports:

  • A full webpack config with a simple preset entries map for simple starter plugins ( front.js, admin.js, blocks.js or something like that ) to provide a simple zero-config option
  • A function that takes an entries map and outputs the full webpack config with recommended values.
  • Each part of the recommended config as their own keys.

The discussion provided good input for further iteration. Next, progress was shared on the format command, which aims to provide autoformatting functionality using Prettier and Eslint autofixers. It is still in an experimental state, but would provide a powerful tool for developers to more easily adhere to coding standards.

Agenda: Linting

Slack Conversation

We discussed the lack of ES2015+ rules in the WordPress JavaScript coding standards. A pull request was proposed on Gutenberg which makes using Object shorthand notation required for Gutenberg JavaScript. We agreed this was a desirable standard to have for ES2015+ code. For now, we decided to include the rule in the Gutenberg coding guidelines until a formal proposal to include ES2015+ rules in the WordPress JavaScript coding standards is drafted.

Agenda: E2E tests in core

Slack Conversation

Progress is being made on making Gutenberg’s e2e test functionality reusable for WordPress core and beyond. @gziolo gave the following status update:

  • Added package for Axe API integration with Jest and Puppeteer: https://github.com/WordPress/gutenberg/pull/13241. This is set of tools for accessibility static analysis which we want to integrate with e2e tests to ensure that we can catch regressions early on.
  • Extracted test utils to their own @wordpress/e2e-test-utils package: https://github.com/WordPress/gutenberg/pull/13228. It will allow some code reuse for those who would like to start writing e2e tests for their WordPress sites, plugins or themes.
  • Moved tests to their own @worpress/e2e-tests package: https://github.com/WordPress/gutenberg/pull/12465. There are now located in packages/e2e-tests/specs folder.

@gziolo plans to continue working on enabling a11y support to e2e tests in Gutenberg next. In order to start reusing the e2e setup in WordPress core, quite some configuration is still needed in WordPress core. This is tracked in https://core.trac.wordpress.org/ticket/45165. @adamsilverstein agreed to explore this further.

Agenda: PropTypes and React Doc Generation

Slack Conversation

@ajitbohra proposed to add PropTypes to components in Gutenberg, in order to allow automated documentation generating and have type checking for components.

There was interest in the idea but also some concerns were raised:

  • There is some uncertainty of PropTypes’ future, considering that Facebook doesn’t use them and there exist other type systems which supersede them (Flow, TypeScript). PropTypes seems like a good solution for what we need right now, but in terms of type system, there might be better solutions available.
  • If they’re added, we need to make sure they are added as part of a proposal which also includes how they are going to be used, ie. for auto-documentation.

For now, we decided to avoid to add complexity without clearly understanding the merit. More exploration is needed on auto-documentation and the benefits of strong typing.

#core-js, #javascript, #meeting-notes, #summary

Riad Benguella 3:50 pm on December 18, 2018
Tags: core-js, ,   

JavaScript Chat Summary – December 18th

Below is a 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 agenda (January 8th).

Next meeting

This is the last meeting of the year. The next meeting will be held on January 8.

WordCamp US contributor day

A lot of fruitful contributions and discussions happened during the WCUS contributor day:

  • @herregroen made some progress toward improvements in how JSDoc are extracted and surfaced to developer documentation. More info in this slack thread and core ticket.
  • A Pull Request bringing aXe accessibility e2e testing in the Gutenberg repository has been created. The folks at Deque published a blog post about their takeaways.

Node 10.x LTS

The new versions of Gutenberg packages now require Node 10 or newer. This is to align with our stated support to follow the LTS release cycle of Node.

ESlint Package

The first version of the @wordpress/eslint-plugin package including recommended WordPress ESLint configuration has been published. A post detailing all the guidelines bundled in this package has been shared.

Action items:

  • Clarify in the docs and the package.json that the package requires eslint-plugin-react, eslint-plugin-jsx-a11y and eslint as peer dependencies.

JavaScript Documentation effort

There is an agreement that we need a bigger documentation effort to clarify some misunderstanding about the internals of Gutenberg.

Related:

  • If you have some technical knowledge and are interested in helping the documentation efforts, please have a look at this call for contributors.
  • Yoast is working on some extensibility APIs docs.

Documentation will be discussed further on the next meeting.

Open floor

#core-js, #javascript #summary
Omar Reiss 6:07 pm on December 5, 2018
Tags: core-js, , ,   

Javascript Chat Summary – December 4, 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: 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 #summary
Riad Benguella 12:41 pm on October 31, 2018
Tags: core-js,   

JavaScript Chat Summary – October 30th

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.

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

Omar Reiss 1:39 pm on October 19, 2018
Tags: core-js   

5.0: JS package inclusion update

News from the #core-js front! The JavaScript packages published on NPM have been included in WordPress core. Initial work on this was done last week by @atimmer. This week we were able to finalize the work after processing some feedback that we had received.

How does it work?

In the 5.0 branch, you can now run npm install && grunt build:js. That will download the NPM packages and build the scripts that need to be registered. Updating a script is a matter of changing its version number in the package.json and running the same command again.

Tasks

We’ve got the following tasks left:

Must haves for RC

Should haves for RC

Nice to haves for Beta, maybe RC

Jeffrey Paul 12:37 pm on October 10, 2018
Tags: , , , , core-js, , , , , , ,   

Dev Chat Summary: October 10 (5.0 Week 2)

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

5.0 planning

  • See @pento’s WordPress 5.0 for Contributors and Committers post:
    • “If you’re an experienced contributor or committer who has time available during the WordPress 5.0 release cycle, and want to be able to make meaningful contributions towards making WordPress 5.0 awesome” … “Please reply to this post with information about your availability, what components of WordPress you have experience in, and (if you haven’t got involved with Gutenberg yet) what you feel has been getting in the way.”
    • In that post are some direct actions you can take to help contribute to 5.0, otherwise please review and comment if you’ll be around during the 5.0 release cycle… thanks!
  • Also see review @pento‘s 5.0 commit/branch details if you plan to contribute during the 5.0 release cycle
  • @pento: if you have time to help, please review tickets in the 5.0 milestone to determine whether to keep it in 5.0 (Gutenberg-related), or move to 5.0.1 (other bug fix) or 5.1 (other feature)
  • @kadamwhite: request for help testing Lazily Evaluate Translation Strings (#41305) with input requested by the end of this working week to help remove the blocker to further Gutenberg localization work
  • Plans for an updated readme.html to be committed with contributions open until RC
  • @chanthaboune: collecting blocker items and dates across team reps, will post listing to Make/Core, if you have items to add to the listing please ping @chanthaboune directly
    • @matt: 5.0 baseline and goal is 4.9.8 + Gutenberg, thus a lot of things that may have been considered blockers in past major releases are probably going to be reclassified as “nice to have”
  • @matveb: last JS package included in the Gutenberg 4.0 RC, on track and could be ready for end of the week

Updates from focus leads and component maintainers

General announcements

  • See @matt‘s post for details on the Gutenberg Phase 2 Leads, @alexislloyd (design and product) and @youknowriad (technical)
    • Phase 2 is about thinking outside the box, namely the post and page box, to allow Gutenberg to handle entire-site layouts. We will replace widgets with blocks, so any block will be able to be used in any registered “sidebar” for legacy themes, and we will upgrade “menus” to a navigation block.
    • Phases 3 and 4 of Gutenberg at WordCamp US in December.
  • @audrasjb: a11y team reorganizing, will discuss during next week’s meeting
  • @chanthaboune: as teams identify new/updated team reps, please follow notes on team rep orientation

Next meeting

The next meeting will take place on October 17, 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.

#5-0, #a11y, #core, #core-editor, #core-js, #core-media, #core-php, #core-restapi, #dev-chat, #gutenberg, #summary, #team-reps

Riad Benguella 12:21 am on October 3, 2018
Tags: core-js   

Technical overview of Gutenberg integration

To better understand how we can integrate Gutenberg into WordPress, it’s crucial to know how the Gutenberg plugin is organized.

JavaScript Packages

The Gutenberg plugin is mostly a JavaScript application composed of several packages. Each one of these packages is:

  • Generic and available as an npm package.
  • The Gutenberg Plugin registers each package as a WordPress script.
  • The Gutenberg Plugin makes the public API of each package available in the wp global variable.
  • If a package is dependent on another one, it consumes it as a global variable and adds it as a dependency of the WordPress registered script.
  • A package can have one or multiple CSS stylesheets.

For example:

A @wordpress/components npm package is registered in the plugin as a wp-components WordPress script; its API is available in the wp.components global variable; and depends on @wordpress/element.

In turn, @wordpress/element‘s script is wp-element and is consumed by @wordpress/components in the bundled script as wp.element.

Bootstraping the editor’s page

To display the editor’s page we call wp.editPost.initializeEditor from the higher-level wp-edit-post package. This function takes as arguments the post to be edited and some editor settings.

This call is made when loading the edit.php page localizing the required arguments and enqueuing the wp-edit-post script.

REST API endpoints

Once the editor’s page rendered, all the communication with WordPress happens using REST API calls. In addition to the regular REST API endpoints to fetch, update and delete taxonomies, posts, etc., Gutenberg adds new REST API endpoints that include:

  • Autosaving endpoint.
  • Reusable Blocks endpoint.
  • Root endpoint for site settings.

Many other tweaks have been necessary in existing endpoints (taxonomies, embeds, permalinks, post search, etc) and most of these have been merged in the previous 4.9.* releases.

MetaBoxes

To support MetaBoxes, Gutenberg hooks initially render the content of the MetaBoxes in a hidden DOM node rendered using a PHP script. We also hook into the post.php call to persist the MetaBoxes save call.

Summary

So, as a high-level picture, the Gutenberg plugin is composed of:

  • JavaScript scripts and styles.
  • A PHP file to bootstrap the editor in edit.php.
  • REST API endpoints.
  • PHP utilities to parse, register and render blocks on the front-end.
  • PHP script to inject the MetaBoxes into the page and hooks to save the MetaBoxes.

Integration Process

In previous JavaScript meetings, we discussed the packages integration approach:

Since the JavaScript scripts are built as reusable npm packages, we’ll consume them in WordPress like any other npm package:

  • Adding a dependency in Core’s package.json.
  • Exporting the wp.* globals in enqueue scripts inside WordPress Core.
    • Example: wp.components = require( '@wordpress/components' );
  • Moving the script registration corresponding to each package into wp-includes/script-loader.php.

Scripts like wp.shortcode, wp.a11y.speak, wp.utils.WordCount can be replaced by their corresponding npm packages. This has already been proposed for the shortcode package and should continue for other packages.

The work being done in #core-js meetings to align the JavaScript guidelines (code style) between Gutenberg and Core would result in a formal @wordpress/eslint-preset package that should be used as a replacement for the current JSHint config.

The REST endpoints should be moved to the regular REST endpoints location in WordPress Core wp-includes/rest-api/endpoints.

The PHP utilities and classes should be moved to wp-includes.

Some minor tasks are also left to do in the Gutenberg repository:

  • Drop the Gutenberg name from all the PHP APIs still using it.
  • Finalize the block-library and edit-post packages:
    • HTML Block and Freeform block to be moved to the npm packages.
    • The creation of the edit-post package.

Test Suite

The e2e tests are crucial to avoid regression when making updates to WP-Admin. The e2e test infrastructure and the tests themselves should be moved to WordPress Core and their stability can be considered a metric for the success of the integration process.

Unit tests, in general, live next the code being tested. For packages, these will stay in the Gutenberg repository and, for the files moved to Core, the tests will follow.

What about the Gutenberg Plugin?

After WordPress 5.0 is released, the Gutenberg plugin will continue to exist. Its purpose will be changed to the development and the maintenance of the WordPress npm packages, including the editor itself, and will also serve to develop the second phase (site customization) of the Gutenberg project. Plugin updates will continue to be released during the 5.0 cycle.

The PHP part of the plugin won’t be needed anymore, as the plugin will just register new versions of the scripts of the packages to replace the ones already registered by Core.

Jeffrey Paul 3:58 am on September 28, 2018
Tags: , , , , core-js, , ,   

Dev Chat Summary: September 26th (4.9.9 week 7)

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

4.9.9 and 5.0 updates

  • @schlessera: just about time to begin work on the 5.0 release cycle
    • @antpb and I will step back as release leads and wind down the 4.9.9 release
    • Over the next couple of weeks we will start coordinating the transition to ease into 5.0 release cycle
    • Will review the work that teams are already in the middle of and determine how best to proceed
    • Announcing this change as soon as possible to provide a longer transition period to smoothly transport as much work over as possible
  • @chanthaboune: “I lead the open source teams at Automattic and am a full time sponsored volunteer to the WordPress Project.”
    • We will reach out to team reps, discuss what you’ve been working on, and what we can do to keep things moving forward so that we can make sure everyone is heard as we settle in for 5.0
    • Current understanding is that @matt is leading 5.0 and any other leads are yet to be determined
  • @jorbin: concern with canceling 4.9.9 due to upcoming PHP7.3 release, some things need to be done to make sure WordPress runs fine on this new version of PHP, I want to ensure the version of WordPress in use on December 13th is compatible with PHP7.3, a very small scoped 4.9.9 may still be needed from myself and ideally @sergeybiryukov @pento @schlessera as well
  • @desrosj: #44416 and #44771 appear to be the open PHP 7.3 compatibility tickets in Trac
  • @pento: seems possible to wrangle a small 4.9.9 release with PHP 7.3 related bug fixes, while 5.0 is ramping up
  • @matveb: Gutenberg leads are near ready to start planning merge proposal for Gutenberg, currently focused on finishing the core Gutenberg tasks, @youknowriad has made a proposal for how JS packages could work
  • @youknowriad: recommend iterative merge vs. a big merge proposal, technical proposal on how this would work was shared in #core-js meetings
  • @sergeybiryukov: some new hooks or enhancements already backported to the 4.9 branch, will need to determine whether or not that should be reverted
  • @jeffpaul: in summary… (1) it appears like a possible agreement with @jorbin @pento (and possibly others who’ve been “voluntold” but yet to confirm) to work on a 4.9.9 focused solely on PHP 7.3 support and (2) @chanthaboune will review existing 4.9.9 work with team reps to see how that should be handled with the 5.0 cycle likely starting shortly

Updates from focus leads and component maintainers

  • The Editor / Gutenberg team released v3.9 last week including the ability to create reusable templates of blocks and exporting them to a JSON file
  • The JavaScript team posted this week’s meeting summary and specifically called for help looking for npm maintainers, so please let them know if you’re interested and available. Related to that, @youknowriad shared #44987 and is looking for review there.

General announcements

  • @psykro continues to look for review and feedback on the alternate devchat proposal
  • @joyously: Theme Review Team discussing what to allow theme authors to put in the admin, possibly allowing themes the same interface as plugins do with a readme.txt file and a View Details link to enhance the theme documentation, change logs, screenshots, upsells. Will look to have discussion in Core Trac ticket or Make/Themes post (and cross-post to Make/Core).

Next meeting

The next meeting will take place on October 3, 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-9, #5-0, #core, #core-editor, #core-js, #dev-chat, #gutenberg, #summary