Agenda: Changelogs

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.

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

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