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 wordpress.org 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 https://github.com/WordPress/gutenberg/pull/7556 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 https://github.com/WordPress/gutenberg/pull/7640

Code Style

There have been new proposals with regards to code styling:

Decision:

  • 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: https://core.trac.wordpress.org/ticket/44371.
  2. Move all JS build config to Webpack: https://core.trac.wordpress.org/ticket/43731.

@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